define managed service replacement authority across version skew

Problem

An intentionally downgraded Desktop cannot currently activate its bundled managed-service version when a newer service is already running.

The current replacement predicate is directional: a newer client may replace an older service, but an older client may not replace a newer service. Desktop therefore fails with a version mismatch instead of completing the rollback.

The alternative attempted in #42185 was also wrong: allowing an older Desktop to accept a newer service would produce a partial rollback where the UI is old but the server remains new.

We need to decide who has authority to replace the shared managed service across version skew before changing this policy again.

Related context:

• #42023 added caller-defined compatibility predicates.
• #42185 proposed accepting same-or-newer services and was closed because it prevents a real Desktop rollback.
• Autonomous replacement ping-pong has not been reproduced in current behavior. It is a hazard to probe if unrestricted starter-wins replacement is proposed, not a current bug.

Confirmed Repro

Intentional Desktop rollback fails

1. Launch Desktop/service version B.
2. Confirm the managed service health reports B.
3. Install and launch older Desktop version A.
4. Desktop A requests exact service version A.
5. Replacement is denied because A is not newer than B.

Actual: Desktop A fails with a version mismatch.
User intent: roll back both Desktop and its managed service to A.

This is the only confirmed user-facing version-policy failure in scope today.

Scenario Matrix

Build executable process-level repros for each row. Every repro should record client version, service version, service instance identity, PID, registration changes, stop/start events, returned endpoint, and final health.

Scenario	Starting state	Action	Result to decide
Normal upgrade	Service A	Launch Desktop B	Does B replace A and connect to B?
Intentional rollback	Service B	Launch Desktop A	Does A replace B, isolate, or fail clearly?
Stale CLI	Service B used by Desktop B	Run CLI A	May an incidental old client downgrade B?
TUI reconnect	TUI A was connected to service A; service becomes B	Force transport reconnect	Does TUI A adopt B or preserve version intent?
Concurrent versions	No service, or service A	Launch A and B concurrently	Which request owns the final version?
Alternating launches	Stable service, then bounded A/B launch sequence	Launch A, B, A, B	Does the sequence settle, reject, or repeatedly replace?
Restart persistence	A rollback decision completed	Restart Desktop/machine	Does the selected version remain stable?
Active work	Service B is streaming or running a tool	Request authorized replacement with A	Is replacement blocked, drained, interrupted, or recovered?
Capability skew	Incumbent lacks authenticated stop/replacement support	Request replacement	Does the client fail clearly, isolate, or use another recovery path?

The alternating-launch case must not be described as a current ping-pong bug unless the executable repro demonstrates autonomous repeated replacement after the bounded launch inputs stop.

Decisions Required

1. Does an explicit Desktop launch own the desired managed-service version, including downgrade?
2. Is downgrade authority Desktop-specific, or do CLI startup, reconnect, restart, and update preflight share it?
3. Must successful rollback guarantee exact Desktop/server version alignment?
4. May an older client adopt a newer service? If yes, what explicit compatibility contract authorizes it?
5. How do conflicting simultaneous starters select one stable owner?
6. Does reconnect retain the initiating client's version intent or adopt the elected service?
7. What happens when replacement cannot be negotiated: clear failure, isolated service, user confirmation, or another state?
8. What compatibility guarantees exist for databases, durable events, configuration, and protocols when running older server code after newer server code?
9. What user-visible result is required when rollback cannot safely complete?

Safety Invariants

These should hold regardless of which upgrade/downgrade policy we choose:

• A successful operation ends with one healthy registered service owner.
• A caller either receives a live compatible endpoint or a clear error; it must not report a successful rollback while retaining the wrong server version.
• Concurrent same-policy ensure calls converge on one final owner after arrivals stop.
• An unauthorized client neither stops the incumbent nor starts a replacement.
• A stale replacement request cannot stop a successor instance.
• An authorized replacement does not start its successor before the incumbent exits.
• Registration publication and cleanup preserve exact instance ownership.
• Rejected, timed-out, unsupported, and accepted-but-not-exited stop paths have bounded outcomes and do not silently create a second owner.
• Contention is bounded per caller and settles after new requests stop.
• Replacement does not permit simultaneous old/new execution ownership of the same session.

These are target invariants for the design and repro suite, not claims that current code already proves all of them.

Required Evidence Before Implementation

• Scriptable repros for normal upgrade, intentional rollback, stale CLI, concurrent versions, and alternating launches.
• At least one real-process concurrent test, not only a pure policy unit test.
• Version and exact instance identity captured before and after every transition.
• A stated expected result for every scenario row.
• Regression tests covering old-to-new, new-to-old, and a replacement-capability boundary.
• If active-work replacement is supported, a durable recovery test that proves there is no overlapping execution ownership. Do not claim exactly-once provider calls or tool side effects.

Out Of Scope Until Reproduced

• Claiming current autonomous A -> B -> A -> B ping-pong.
• Assuming semver ordering implies protocol or storage compatibility.
• Claiming all downgrades are safe without proving backward compatibility of persisted state.
• Prescribing authenticated stop, PID fallback removal, service isolation, or another mechanism before the scenario outcomes are agreed.

Start by building the required scriptable process-level repros for normal upgrade, rollback, stale CLI, concurrent versions, and alternating launches. Capture versions, instance identity, PIDs, registration, lifecycle events, endpoints, and final health for each scenario. Done means agreed outcomes for every matrix row, real-process concurrency coverage, and regression tests for both replacement directions and capability boundaries.