Story-2358: Forum as catalog-backed EditableChoice

The forum is where a matter is actually heard — the Gujarat Electricity Regulatory Commission, the Bombay High Court, NCLT Mumbai. It sits at the top of the Brief's Case particulars rail, and until this change it was a wall: Vega read a tribunal name out of the documents and printed it. If the framer misread the venue, or the matter moved, counsel had no way to say so.

This is the first catalog-backed Editable Surface. Every promotion before it (Key instruments, Governing law, Relief) edited a frame fact — free text counsel owns outright. The forum is different: it is a pointer into a firm-managed catalog. That single difference is the whole Story, and it is what made the obvious implementation wrong.

The gate that had to pass first — and did not

The Brief's FORUM block renders two lines, and they are not the same kind of thing:

src/components/matter-detail/brief/matter-brief-sections.tsx

const tribunal  = brief.canonical.forum?.name || textField(frame, "tribunal_name"); // line 1
const forumType = textField(frame, "forum_type") || matter.forumType || "";         // line 2

The real home of the forum is not the frame at all:

MatterBriefCanonicalView.forum
  → "The Main proceeding's forum (proceedings.forum_id -> forums);
     null when the Main proceeding has no forum set."

So the forum lives on proceedings.forum_id, pointing into the firm's forum catalog — the same catalog Settings already manages. To change it you must PATCH the proceeding, not the frame.

Line 2 has no catalog — and is out of scope

The muted second line (forum_type, e.g. "Domestic arbitration") looks like it wants a picker too. It does not get one here, because no firm catalog enumerates its vocabulary:

What shipped

1. The proxy, first. The generated useAppUpdateMatterProceeding mutation had no browser→server route, so it would have 404'd. Per AGENTS.md ("build the proxy as step one"): a new PATCH handler at /api/internal/matters/[matterId]/proceedings/[proceedingId], its toBrowserRoute mapping, and a mattersGateway.updateProceeding method. Inbound JSON is parsed with the generated request schema and the response is re-asserted against ProceedingView (HR-21) — no as T at the boundary.
2. The picker. ForumChoice loads the firm's catalog via useAppListForums and writes the Main proceeding's forumId. The Main proceeding is found on the detail payload the page already holds (matter.proceedings.find(p => p.isMain)) — no extra fetch, and no backend change was needed.
3. Search-first, on its own. Past 7 options EditableChoice grows a search box (ux-guidelines §1: a long blind list is the same trap as a blind text input). The caller never decides — there is no searchable prop to get wrong. Radix's menu typeahead would otherwise eat the keystrokes, so the search input stops propagation for everything except Arrow/Enter/Escape/Tab, which the menu still owns.
4. Optimistic, with a rollback. On pick, the Brief cache's canonical.forum is patched immediately; the PATCH runs behind it; a rejection restores the snapshot and toasts. The PATCH carries only the id, so the picked name (which is what the rail renders) rides along in a ref.

The empty catalog — the state fixtures hide

Storybook

Honest scope

• No pnpm codegen; no OpenAPI mirror change; no pramaan-functions change. Both endpoints already existed.
• The muted forum_type line is unchanged (see above).
• No other rail field or list was touched. RailFact — whose only caller was the old read-only forum block — was removed rather than left orphaned.
• Staging seam: verified locally (lint, 1264 tests, build, route-registry gate) and in Storybook. The picker against a real firm catalog — and the empty-catalog first run — is exercised in staging UAT after merge; that run, not this PR, is what proves the live path.