fix(cli): validate profile array elements and name --storage-domain

[chrischall]

Both nits from the auto-review follow-up issue.

profiles.ts — per-element validation

validateProfile only Array.isArray-checked captureHeaders / indexedDb / localStoragePointers / sessionStoragePointers / domSelectors. A typo inside an entry passed CLI validation and failed much later at the extension's hello validator, mid-pair, with a ProtocolError that names neither the profile nor which entry was wrong. These arrays are the hand-edited ones — only --capture-header and --dom-selector have flags — so they're exactly where a typo is likely.

Each array now gets a per-element shape check, and the error names the index (profile "x" has an invalid "indexedDb[1]").

Deliberately structural: required fields present and string-typed. The protocol's format rules (origin scheme, key/selector character sets, JSON-pointer syntax) stay in @fetchproxy/protocol's validator — duplicating them here would give two definitions of "valid" and they would drift.

multi-domain reads — name the flag, not the library option

Storage reads target exactly one declared domain. With several declared and none picked, the message that reached the user came from the server:

FetchproxyServer: this MCP declared multiple domains ["a.com", "b.com"] — pass { domain: '<one of them>' } on every per-call request

There is no object for a CLI user to pass. Two changes:

• fpx cookies|local-storage|session-storage|indexeddb and fpx dom refuse up front, next to the existing scope-narrowing checks, mirroring fpx pair's --domain check. Both verbs read unconditionally, so the gap is provable without connecting — and a usage error must not cost a bridge round-trip or trigger pairing. A test asserts listen() was never called.
• fpx session can't pre-check: a captureHeaders-only profile is legitimately multi-domain and never does a domain-scoped read (bootstrap only threads storageDomain into the cookie/localStorage/sessionStorage/IDB reads). So mapBridgeError rewrites the server's message there — keeping the declared-domain list, swapping the hint for --storage-domain.

One behavioural note: that rewritten path returns EXIT.USAGE (1) instead of EXIT.BRIDGE (2). It is a usage error — the bridge is fine, the invocation isn't — and a script distinguishing "retry" from "fix your command" was previously told the wrong one.

Verification

npm run build && npm test (CI's exact commands): 982 passed, npm run typecheck clean. Six new tests; reverting packages/cli/src fails five of them (the sixth is the over-rejection guard, which correctly passes either way).

Closes #152

🤖 Generated with Claude Code

https://claude.ai/code/session_011DKSBmZAgtkp3wfCB4TgMm

[claude]

Claude finished @chrischall's task in 2m 19s —— View job

---

Review complete

• Read CLAUDE.md conventions
• Fetch PR diff
• Review profiles.ts per-element validation
• Review storage-scope.ts + verb wiring (dom.ts, read.ts)
• Review bridge-errors.ts rewrite for session
• Review new/updated tests
• Post findings + verdict

No issues found. This is a tight, well-scoped fix:

• profiles.ts: ELEMENT_SHAPE per-array checks map 1:1 onto the actual @fetchproxy/protocol decl shapes (CaptureHeaderDecl, IndexedDbScopeDecl, PointerDecl, DomSelectorDecl in packages/protocol/src/frames.ts), and correctly stay structural (presence + string-typed) rather than duplicating the protocol validator's format rules — matching the PR's stated intent. The ${k}[${i}] error naming is verified by the new profiles.test.ts cases, including the non-object-element and empty-keys-array cases.
• storage-scope.ts / dom.ts / read.ts: requireStorageDomain is called before server.listen() in both verbs, matching the "usage errors must not cost a bridge round-trip" comment, and the new tests assert server.listen was never called.
• bridge-errors.ts: the regex / — pass \{ domain.*$/ exactly matches the real server string built in packages/server/src/ws-server.ts's resolveBaseDomain (`FetchproxyServer: this MCP declared multiple domains [${declared}] — pass { domain: '<one of them>' } on every per-call request`), so the rewritten message correctly preserves the domain list and swaps in --storage-domain. Confirmed the EXIT.USAGE (vs EXIT.BRIDGE) behavioral change is scoped correctly: fetch/download/health never hit this branch in practice (assertUrlOnProfile in fetch.ts always resolves and passes an explicit domain; download/health don't thread a domain param at all), so the generic match in mapBridgeError only actually fires for session, as described.
• Wording is consistent with the existing fpx pair multi-domain check in health.ts (runPair).
• CI (build + full vitest suite) is green on this PR.

Verdict: pass

[github-actions]

✅ Auto-review verdict: pass — Well-scoped fix that matches its description exactly: per-element profile validation aligns with the actual protocol decl shapes, and the storage-domain hint rewrite correctly matches the real server error string. No issues found.