Fleet Studio completion: control-gated peer routing and owner safety #1482

Acceptance Criteria

• A peer request carries only that peer’s credential; a hub credential is never forwarded to a peer.
• Owner routing activates only for a target-enforced active Control grant and never depends on a legacy attachment pointer.
• All supported session request forms, permissions, and upgrade paths resolve to the owner; unresolved known remote ownership yields named unavailable/read-only behavior, never local execution.
• Owner state survives a transient source failure long enough to preserve remote identity and allow an explicit refresh/recovery outcome.
• Remote file reads/writes require an active bound owner context; absent binding cannot turn a remote Work Column operation into a local operation.
• Control revoke, identity mismatch, or transport loss suspends mutation immediately and leaves the remote session visible/read-only.

Testing Decisions

Extend multiplexer dispatch and owner-routing suites with peer-specific authorization, dynamic rotation, all session path forms, owner-map loss/refresh, forged owner headers, bound file context, and no-local-fallback assertions.

Key Decisions

Known remote owner is a fail-closed routing state, not a hint that may fall through to local.

Constraints & Invariants

Existing legacy attachment behavior remains a compatibility path. This slice does not implement global SSE.

Prior Art

#1448, #1449, existing multiplexer foundations, and ADRs 0031–0032.

Source

Part of #1475. Blocked by #S3, #S4, and #S5 (native edges wired after creation). ADR 0034.

Binding Amendment

Peer proxy credentials and endpoints are resolved dynamically per request. A known remote owner may refresh or return named unavailable, but never resolve locally. Every owner-bound file operation must carry verified bound-owner context; a forged owner header cannot bypass Control.