fix: format CliError/ArgumentError instead of leaking a raw stack trace in web fetch

[Agnik47]

Description

webcmd web fetch is dispatched on the client-owned fast path in src/main.ts (argv[0] === 'web' && argv[1] === 'fetch'), before adapter discovery and before the hosted-mode branch, which calls runClientOwnedWebFetch directly. That function (src/fetch/command.ts) had no try/catch, and the call site is outside the CliError handling every other command routes through in commanderAdapter.ts. Any thrown CliError (e.g. FETCH_BLOCKED) or ArgumentError from clientOptions() therefore escaped straight to Node's default uncaught-exception handler as a raw stack trace, instead of the structured error output the rest of the CLI produces.

Before

$ webcmd web fetch --url https://news.ycombinator.com
file:///…/dist/src/fetch/client.js:67
                throw new CliError('FETCH_BLOCKED', 'The site blocked non-browser fetches.', …);
                      ^
CliError: The site blocked non-browser fetches.
    at webFetch (file:///…/dist/src/fetch/client.js:67:23)
    at async runClientOwnedWebFetch (file:///…/dist/src/fetch/command.js:40:20)
    at async file:///…/dist/src/main.js:74:9 {
  code: 'FETCH_BLOCKED',
  hint: 'Use webcmd web fetch-browser for this URL.',
  exitCode: 1
}

After

$ webcmd web fetch --url https://news.ycombinator.com
ok: false
error:
  code: FETCH_BLOCKED
  message: The site blocked non-browser fetches.
  help: Use webcmd web fetch-browser for this URL.
  exitCode: 1

Same shape as any other command's error — verified by reproducing a real command's CliError through the normal commanderAdapter.ts path and comparing the envelope byte-for-byte with what this fix now produces on the fast path.

Fix

Wrapped the body of runClientOwnedWebFetch in a try/catch. On error, it now builds the same ErrorEnvelope (toEnvelope) and renders it with the same formatErrorEnvelope used by commanderAdapter.ts, writes to stderr, and sets process.exitCode from err.exitCode when it's a CliError (falling back to EXIT_CODES.GENERIC_ERROR otherwise) — matching resolveExitCode's behavior. output.js is imported dynamically inside the catch block so the happy path (the common case) doesn't pay for cli-table3/js-yaml on this fast path.

This covers both cases called out in the issue: a CliError thrown from deep inside webFetch() (e.g. FETCH_BLOCKED), and an ArgumentError thrown synchronously by clientOptions() for bad flags.

Fixes #246

Type of Change

• 🐛 Bug fix
• ✨ New feature
• 🌐 New site adapter
• 📝 Documentation
• ♻️ Refactor
• 🔧 CI / build / tooling

Checklist

• I ran the checks relevant to this PR
• I updated tests or docs if needed
• I included output or screenshots when useful

Screenshots / Output

npm run typecheck and npm run build pass, generated artifacts stay byte-identical (git diff --exit-code clean after build).

Added two regression tests to src/fetch/command.test.ts (mocked webFetch/clientOptions, no real network calls) covering the CliError and ArgumentError paths:

$ npx vitest run --project unit src/fetch/command.test.ts
 Test Files  1 passed (1)
      Tests  4 passed (4)

Full src/fetch/ suite also passes (22/22).

[github-actions]

🟢 No documentation gap found — medium confidence

The automated review found no documentation gap in the supplied changes.

This review is advisory and does not block merging.