v2-platform: 07 all web plugins grafted — expand-contract migration off the monolith

Parent

#274 (v2 platform services spec)

What to build

All web plugins as grafted remotes — the expand-contract migration of the existing monolithic UI: plugin-by-plugin, the current route tree splits into independently deployed web-plugin remotes (public, anon, authenticated, admin surfaces), each grafted through the engine from the grafting ticket, with auth, locale, and the typed API client injected via root-route context. The monolith keeps serving until every surface is grafted and verified, then the flip removes it. Route collisions resolve first-wins with namespaced ids. This is the ticket that makes the real application fully composed from MF remotes.

Acceptance criteria

• Every existing UI surface (public, anon, authenticated, admin) renders from a grafted remote plugin after the flip, feature-parity verified by the regression browser suite
• Auth gating, locale behavior, and apiClient usage work identically to the monolith
• The flip is atomic: no window where surfaces are served half-monolith/half-grafted
• Each web plugin builds and deploys independently through the deploy service
• The monolith is deleted at contract time with no remaining callers

Blocked by

• #276 (grafting engine in the real host)

Start by reading parent issue #274 and the blocked grafting-engine issue #276 to understand the required host integration. Use the regression browser suite to compare all public, anonymous, authenticated, and admin surfaces with the monolith. Done means every surface runs from independently deployed remotes, the flip is atomic, and the monolith has no remaining callers.