[OoP] ToolKit OoP: Out-of-Process Gear Support

[mattgarmon]

Description

Implement out-of-process (OoP) gear deployment for ToolKit so gears can run as standalone HTTP-serving processes with deployment transparency.

Target: K8s (Profile 3) first. Auth uses two planes (ADR-0008): a tenant plane (user JWT, re-validated per hop) and a platform plane (tenant-less gear identity — K8s SA tokens this phase, mTLS+SPIFFE next).

Scope: P1 only — Profile 1 (Embedded) + Profile 3 (K8s Native).

• Profile 2 (Host + Workers), gRPC hot paths, Mode B (external edge), Identity Broker, multi-cluster, and mTLS+SPIFFE are deferred to a later phase.
• The trust-coupled core (authz-resolver, tenant-resolver, resource-group, account-management) stays co-located in the Platform Host.
• OoP-8 adds the infra REST surfaces that unblock OoP business gears. See DESIGN.md § Platform Host Composition for the rationale.

Reference docs: PRD | DESIGN | ADRs

Phases

Work is distributed by ticket dependencies (the Depends on column / graph below) — any phase whose dependencies
are met can be picked up in parallel.

Phase	Name	Effort	Depends on
OoP-1	SecurityContext HTTP Propagation (JWT Re-validation)	Small–Medium	—
OoP-2	Platform-Plane Authentication (K8s SA Tokens)	Small–Medium	—
OoP-3	DirectoryService REST-Endpoint Discovery (register/resolve REST endpoints)	Medium	—
OoP-4	OoP Bootstrap — HTTP Server + Probes (Axum, /healthz, /readyz)	Large	OoP-1, OoP-2, OoP-3
OoP-5	GatewayProvider + ToolKitGatewayProvider (reverse-proxy abstraction)	Medium–Large	OoP-4
OoP-6	REST Client Codegen Wiring (DirectoryService → ClientHub)	Small	OoP-4
OoP-7	K8s Packaging (Helm library + umbrella charts)	Medium–Large	OoP-1, OoP-2
OoP-8	Platform Host + Infra REST Surface (AuthZ, Tenant Resolver, Types Registry, CredStore)	Medium	OoP-1
OoP-9	Integration Testing & Validation (round-trip, benchmarks, edge)	Medium	OoP-5, OoP-6, OoP-7, OoP-8

OoP-1 (JWT re-validation) ─┐
OoP-2 (SA tokens)          ┤→ OoP-4 (HTTP server, probes, registration, deps, drain)
OoP-3 (REST discovery)   ──┘        │
                                    ├→ OoP-5 (gateway)─────────┐
                                    └→ OoP-6 (client wiring*) ─┤
OoP-7 (Helm charts)  ──────────────────────────────────────────┤→ OoP-9 (integration tests)
OoP-8 (infra REST; dep: OoP-1) ────────────────────────────────┘

No hard deps; start in parallel: OoP-1, OoP-2, OoP-3, OoP-7.
* OoP-6 is additionally gated on integrating PR #4084.
Soft: OoP-2 should protect OoP-3's new register/resolve RPCs before Profile-3 exposure (enforced at orchestrator wiring, not inside OoP-3).

Doc Maintenance (tracked here)

• Update DESIGN.md § "SecurityContext API Gap" after OoP-1/OoP-2
• Decide API versioning strategy for OoP gear rolling upgrades — during OoP-9
• Integrate PR feat(modkit-contract): add PoC contract stack for REST and gRPC #4084 — reconcile modkit/toolkit naming, then update DESIGN.md's "REST Client Codegen … implemented" claim to point at it
• set_bearer_token is intentionally out of P1 (only needed for the in-process gRPC decode_bin path); revisit if OoP gRPC tenant hot-paths are added (P2)
• Confirm "Flight Control" remains realized by gear-orchestrator (no separate gear in P1)