Z5 dependency: per-subject credential resolution at the injector

Tracking stub for the third slice of #220, so all of its replacements are discoverable from this repo.

The work itself lives in rossoctl/cortex#905 — per-subject credential resolution in AuthBridge's static-inject, the deferred per-user half of Z5 (docs/specs/2026-06-19-m13-generalized-credentialed-egress-design.md; docs/specs/README.md:152 records RC1 as implementing only the static single-tenant slice).

Note: the P5 spec §6 and ADR-0032 still name that repo kagenti-extensions. It has been renamed and redirects to rossoctl/cortex.

Why this stub exists — the claim boundary

From the P5 spec §7: #239 makes the harness send a per-request subject and carry an inert placeholder instead of a real key. Nothing resolves that subject into a credential until cortex#905 lands.

So #239 makes the system tenancy-neutral; it does not make it multi-tenant safe. End-to-end multi-tenant safety is not claimable — and must not be advertised — until cortex#905 is done. This stub exists so that boundary stays visible from the repo where the density and isolation claims are made.

Relationships

• Split out of #220, alongside #239 and #240.
• Blocked by #239 (the injector cannot key on a subject the harness never sends).
• Implemented in rossoctl/cortex#905.

Read docs/specs/2026-06-19-m13-generalized-credentialed-egress-design.md, docs/specs/README.md:152, and the linked cortex#905 issue for the implementation boundary around AuthBridge's static-inject. Confirm #239 supplies the per-request subject; this stub is complete when cortex#905 provides per-subject credential resolution and the multi-tenant claim can be made safely.