Provider loss during update can leave turns permanently running or starting

Problem

When a T3 server update or restart stops a provider subprocess, persisted projection state can remain running or starting even though provider inventory has no live session. The UI then reports “Working” indefinitely. Messages can be durably accepted but never receive a provider response.

A second race exists in the in-app updater: a turn can start while the candidate is downloading, after the updater's initial idle decision but before process handoff.

Expected behavior

• Refuse an update whenever foreground or background work exists, including a second check immediately before handoff.
• On startup, reconcile projected active work against actual provider inventory.
• During normal runtime, automatically interrupt a confirmed missing running provider.
• Automatically clear a provider that remains absent while a session is starting, after a bounded startup grace period.
• Do not interrupt a transient inventory gap or a genuinely live provider.
• Let external update automation reject releases that remove this recovery contract.

Proposed fix

The tested source change implements those guarantees and exposes a versioned provider-lifecycle recovery capability through the service preflight. A focused PR follows.

No files or tests are named. Start with the service preflight, provider inventory, projected turn state, and in-app updater handoff described in the issue; trace startup and runtime recovery paths. Done means the stated races and missing-provider cases are reconciled without interrupting transient gaps, and external update automation enforces the versioned recovery capability.