Phase 4 CA Portal/Admin wiring — two items scoped down, not built

Decision

Of the 9 gaps identified for Phase 4 ("CA Portal + Admin completeness"), 7 were closed by wiring real backend data into existing UI (support-ticket reply threads, dispute SLA + structured resolve panel, consultation message thread, preflight-checklist notes, locked specialisations, client drill-in receipt/summary panels, CA-application pricing/consent/timeline). Two were not built and are deliberately deferred:

1. In-place consultation tier upgrade (/ca/ask/upgrade) — "Upgrade" currently deep-links into a fresh /ca/hire checkout rather than pro-rating/crediting the prior payment against the same engagement. No wireframe exists for a true upgrade flow, and no backend concept of "upgrade an existing consult" exists (ConsultRequestSchema has no tier-upgrade path — an "upgrade" is just a new requestConsult booking). Building real proration would mean inventing new payment logic against .claude/rules/backend.md's money-gate/idempotency rules without a product spec to build against.
2. CA clients-list bulk actions (/ca/portal/clients) — the wireframe shows a checkbox column + bulk toolbar ("File ITR · N", "Export XML · N", "Mark ready · N", "Send pre-flight"). No backend callable exists for any of these as a batch operation (no bulk-file, bulk-export, or bulk-notify endpoint anywhere in apps/functions/src/ca or marketplace) — building the UI would mean fabricating a client-side loop over a batch of calls, since no atomic bulk endpoint exists, or inventing new backend surface not otherwise scoped.

Also deferred (same "no wireframe backing" pattern): CA profile editor's photo upload and credentials gallery (ca_profiles has no photo_url or credentials fields; would need new schema + Storage plumbing). The specialisations-lock part of that same wireframe section was built — see apps/functions/src/ca/profile.ts's updateCaProfile gate.

Why

Matches the standing project convention (established across Phases 2–3): wire what's real, scope down rather than fabricate data or invent backend features without a wireframe or product spec to build against. All four deferred items would require designing new payment logic, new bulk-operation semantics, or new file-upload plumbing from scratch — none of which is "wiring an unused component," which is what this pass is scoped to.

Impact

• /ca/ask/upgrade keeps its current re-checkout behavior; no code changed.
• /ca/portal/clients keeps its current single-row actions; no bulk UI added.
• CA profile editor keeps text-only fields (photo/credentials gallery not built).
• If any of these become a real V1 requirement, they need a wireframe (upgrade flow, bulk toolbar semantics) and/or new backend design (proration, bulk-file endpoint, Storage schema) before implementation — not a follow-up wiring pass.