Extensions — admit one backend service and host-owned projection

[zenithruneblade]

Define one safe backend extension path without turning extension packages into Litestar plug-ins.

This is a bounded child of #63. Canonical law remains in ADR 05 — Extensions, ADR 11 — Backend and ADR 14 — Workers.

The current Vessel composition root is intentionally closed: an extension may not mutate a live Litestar app, inject arbitrary middleware, publish an unreviewed route bundle, start background work during register(), or acquire persistence/effect authority merely because its code was selected. The extensible seam must be a shaped, owner-qualified contribution consumed by the host.

First working slice

• Choose one receiving Core office or accepted Composition and one versioned backend operation/service contract that it owns.
• Register the operation/service definition with stable identity, immutable revision, receiving owner, Contribution kind and Registrant provenance; reject duplicate, ambiguous and unresolved dependencies before assembly seals.
• Adapt that contribution into one host-owned Litestar controller or generic typed projection after whole-generation validation. Route, method, DTO, authentication, error and OpenAPI identities remain host-reviewed and collision-checked.
• Construct runtime dependencies through the Vessel composition root and retire them in reverse ownership order. Registration itself starts no service, opens no connection and schedules no work.
• If durable or asynchronous work is needed, use Workers & Ghouls — durable service jobs and recovery #22's worker/service-attempt contract; do not create an extension-owned scheduler, queue protocol or recovery ledger.
• Declare persistence, secrets, network/effect authority, artifacts and lifecycle separately. Coordinate schema work with Persistence — core SQL models, migrations and async transactions #47/Extensions — manifest, dependency locks, migrations and safe lifecycle #65 and package-generation activation with Packaging — verify a source-bound release candidate on a clean host #45/Evolution — rehearse an update and its recovery path #46/Extensions — manifest, dependency locks, migrations and safe lifecycle #65.
• Verify disabled-by-default assembly, enable → restart → operation visible, authorization refusal, route collision refusal, failed startup cleanup and disable → restart → operation absent without deleting retained data.

Boundary

The result is not a general Controller/middleware import hook. Extensions contribute typed application material to an explicit owner; Core composes the HTTP and lifecycle surface. A new public backend contribution kind requires an accepted owner and amendments to ADRs 05/11 before implementation.

Open decision

Choose the smallest first contract and decide whether its host adapter is a generic operation endpoint or an explicit Core controller adapter. Do not invent an arbitrary route-descriptor language merely to make this issue pass.

Connections: #21 registration, #22 durable jobs, #23 artifacts, #29 application workflow, #42 services, #47 persistence, #65 package lifecycle.
Verification: assembly/duplicate fixtures, Litestar OpenAPI and authorization tests, process restart, and worker/recovery evidence where applicable. Shared contribution rules: #52.