— 03 API 404 FIX — /api/registries/index

Symptom: GET /api/registries/index returns HTTP 404 with the Nitro default body {"error":true,"statusCode":404,"statusMessage":"Page Not Found"}. The /knowledge/registries page (HTTP 200 shell) calls this route for its table data, so the page renders but its data path is dead = a false-green risk (page looks up, data is empty).

Root cause: client/server drift in build s174. The page bundle references /api/registries/index but the Nitro server build registers no handler for it. This is not a DB or query problem; the route simply does not exist server-side.

Decision — should the route exist, or should the caller be repointed? The prior registries-pivot foundation audit recorded an intent to converge /knowledge/registries onto pivot truth, so the registries page is mid-migration. Two clean options, both requiring a rebuild (adding/removing a route changes the compiled Nitro manifest; a host file-drop cannot register a new route):

• Option A (add handler): ship server/api/registries/index.get.ts returning the registry index from Postgres truth. A candidate is staged at patches/registries-index.get.ts — it returns one row per registry leaf from v_count_integrity (code, name, counts, integrity status, pivot_backed) via rpQuery, mirroring the sibling registries-pivot handlers. It must be pass-through to PG truth with no Nuxt count math; before merge, confirm the exact interface the page expects (operator has the page source).

• Option B (repoint caller): change the page fetch from /api/registries/index to an existing route — /api/registry/composition (already 200, registry breakdown) or /api/registries-pivot/summary (pg-backed). Lower surface than adding a route, but still a client rebuild.

Recommendation: Option A if the page genuinely needs a registries listing distinct from composition; otherwise Option B. Either way this is operator rebuild work; it cannot be hotfixed via the bind-mount express path (which only swaps existing handlers). The candidate handler is provided so the operator can choose with the page source in hand.

No live mutation performed for the 404. The staged candidate is action-ready. The smoke harness asserts /api/registries/index = 200 so the fix is verifiable post-rebuild.