Direction request: provider-maintenance lifetime and update/launch admission

[shteudguy]

Would you accept a focused PR for maintenance jobs that survive the requesting WebSocket and coordinate installation mutation with active provider use? The concrete failure reports are #27361 and #31148.

The downstream implementation gives jobs server-owned lifetime, lets an alias join the existing installation job, and lets unrelated installations drain independently before the shared package-manager command lock. A conditional pin batch rejects a stale alias or failed precondition before persistence or secret effects. It retains a foreign pin change during rollback.

The implementation is 16 files on pinned e455200. Focused actual-function checks and the exact e455 compiler-source typecheck passed; live installer E2E and global gate success are not claimed. Source: https://github.com/shteudguy/t3code/tree/fix/provider-maintenance-lifetime (8b3e70c).

The ws.ts seam overlaps #21974. That PR establishes interest in sharing maintenance/scanning services; it does not approve the broader admission, drain or pin-CAS design. Before opening an implementation PR, is this scope wanted, and should the WebSocket sharing seam be left to #21974 or split out?