fix: preserve web backend setup hint

[thymikee]

Summary

Preserve managed backend details when the web provider wraps missing agent-browser failures, so Node <24 users keep the actionable Node 24+ hint instead of seeing only the generic setup hint.

Closes #834

Touched files: 2. Scope stays inside the web provider and its regression coverage.

Validation

pnpm exec vitest run src/platforms/web/agent-browser-provider.test.ts src/platforms/web/agent-browser-tool.test.ts
pnpm check:quick

[github-actions]

Size Report

Metric	Base	Current	Diff
JS raw	1.3 MB	1.3 MB	+47 B
JS gzip	422.3 kB	422.3 kB	+15 B
npm tarball	557.3 kB	557.3 kB	+5 B
npm unpacked	1.9 MB	1.9 MB	+47 B

Startup median (7 runs, lower is better):

Scenario	Base	Current	Diff
CLI --version	24.8 ms	24.7 ms	-0.1 ms
CLI --help	39.8 ms	40.5 ms	+0.7 ms

Top changed chunks:

Chunk	Raw diff	Gzip diff
dist/src/9722.js	+47 B	+15 B

[thymikee]

Reviewed against #834 and the web backend notes. The fix now preserves appError.details through the web provider wrapper and uses the mapped hint for both TOOL_MISSING and COMMAND_FAILED; the daemon production route creates this same provider in request-router.ts, so agent-device --platform web open ... keeps the Node 24+ unavailable reason instead of replacing it with generic setup guidance. Regression coverage exercises createAgentBrowserWebProvider().open() under a Node 22 runtime override, and CI is green. I do not have additional findings; this looks merge-ready.

[thymikee]

Looks correct and tightly scoped. Spreading ...(appError.details ?? {}) before overriding cmd/args/hint is what preserves the version/installDir details, and routing both the TOOL_MISSING and COMMAND_FAILED branches through the shared webBackendHint helper keeps the "use the mapped hint when present, else fall back to the doctor hint" behavior consistent. The Node-22 runtime-override regression test pins exactly the detail that was being lost (the Node 24+ hint plus version/installDir), and the helper restores the original process.version in a finally, so it won't bleed into other tests.

One minor thought: since webBackendHint only ever reads error.details?.hint, it could take the details object directly rather than the whole AppError — trivial, take it or leave it. LGTM.

---

Generated by Claude Code