Register the DXA vertical preset in @dossier/app before building the inline graph

The shared inline graph builder packages/app/src/lib/server/graph-view.ts builds the graph via @dossier/okf's buildGraph (line 23/126), whose edges() extraction unions the core vocabulary with whatever registeredEdgeFields() reports. But @dossier/app never calls registerDxaTypes() — grep-confirmed: 0 matches in packages/app. Until the DXA preset is registered, registeredEdgeFields() is empty, so buildGraph sees only the core edges and silently drops the DXA vertical edges (client/engagements/capabilities/delivered_by/systems/runs/sow).

Both graph consumers are affected:

• /graph — over the configured KB.
• the dev-only /preview/[client] inline client graph (The dev-only client landing preview renders the client's REAL OKF knowledge graph inline — via three atomic no-copy-paste extractions (readKbAtoms(dir), buildGraphView, GraphExplorer) that read the client's served OKF directly without perturbing the process-wide DOSSIER_KB or the prerendered /graph).

So the client↔engagement↔capability spine is under-counted in the rendered graph (the inline RBA graph reported 596 edges — possibly undercounted).

Same class as the docs fix, app-side

This is the app-side mirror of Make the docs renderer registry-aware for vertical edges + render decision judgment fields (done): that fix made the docs renderer registry-aware. The docs site already registers the preset at the surface boundary (packages/site/src/components/OkfRelated.astro:28 → registerDxaTypes()); the app does not. The fix is to register the vertical preset before building the graph — single-sourced from the @dossier/okf registry per OKF edge vocabulary is registry-driven — a vertical declares its own traversable edges, never a hand-maintained edge list.

Why a task, not a fix-in-place

This is a real surface change (where + how the app registers verticals at server init, idempotently, without per-request cost) plus a re-measurement of the graph edge count — owner judgment + code on the SvelteKit app surface, not a one-token hygiene fix. Routed to the Principal SvelteKit Engineer, the owner of @dossier/app. Filed by the log-auditor from the QA pass; confidence: inferred. Board globbed before filing — no open task covered the app-side vertical registration.

Resolution (2026-06-19)

DONE. Closed backlog → done. Verified against source: packages/app/src/lib/server/graph-view.ts imports registerDxaTypes (:23) and calls it once as a module-init side-effect (:40) before any buildGraph/edges() runs — the single shared chokepoint both /graph and /preview/[client] traverse. App-side mirror of the docs fix (Make the docs renderer registry-aware for vertical edges + render decision judgment fields), single-sourced from the @dossier/okf registry (OKF edge vocabulary is registry-driven — a vertical declares its own traversable edges), idempotent, core-first (a vertical can never shadow a core label).

• No regression on Dossier's own KB: /graph held at 118 nodes / 659 edges (its KB carries no DXA edges).
• RBA /preview inline graph: 660 → 718 edges (+58) — capabilities=19, delivered_by=19, client=10, engagements=6, systems=4 now render instead of being silently dropped.
• pnpm --filter @dossier/app check green. The fix is app-surface-only; upstream extraction/loop data untouched; the docs-side fix not regressed.