bug(remote): join enable work and retain failed owners during disposal #941

Expected behavior

Remote disposal closes new enable admission, joins already-admitted enable/disable work and retains the exact server until its stop completes. A rejected stop must remain retryable through the owner that performed the original start.

Confirmed source and regression

At application base 115e26fc9c67316a3b0b1b4318f47f7a2bea3606, RemoteController.dispose() calls teardown outside the enable/disable FIFO. A pending enable can publish a server after disposal returns. teardownLive() also clears this.server before awaiting stop; a rejection leaves a later retry with no server to stop.

Source.

Discovered during #919's composition audit. Implemented in branch fix/quit-service-lifecycle, commit e9b88bf5: terminal enable admission, disposal in the same FIFO, no late live-URL publication, and retained server ownership on rejection. Two added regressions exercise the real controller/server stack with controlled transport start/stop promises. The complete nine-case remote system lane passed. The tests prove ownership and ordering at the transport contract; they do not claim an observed native tunnel-process exit beyond that contract.

Acceptance: delayed start during disposal cannot leave an enabled controller; repeated disposal joins one promise; a failed stop retries the same transport and does not construct a replacement. The forthcoming quit-safety PR may close this specific issue, while broader B02/#919 remains open.

Refs #919 and #918. No live user remote server was stopped.