fix(runtime): wait for locator publication before dispatch

[huangruiteng]

A managed runtime could reply to its first ping, or commit a typed write, while locator publication still held an incomplete cleanup claim. An immediate process exit then stranded the replacement behind that claim until the unchanged lock budget expired.

Dispatch now waits for publication and awaited cleanup to finish; idle retirement also waits for that boundary. This stays in the existing native runtime owner and adds no retry, timeout increase or alternate writer. It addresses S4/S10 startup and abrupt-exit recovery; broader operations qualification remains open.

Validation on df90e0f090f60406bd3674ea444c6fabe0d14935:

• Real Node filesystem/protocol counterexample: pausing exclusive cleanup-claim creation makes both first-ping and first-write assertions fail on the old server. Both pass after the repair, including abrupt exit, replacement write and receipt replay.
• 94 focused Python runtime lifecycle/transport/cache tests and 8 native lock/error tests passed; control-plane TypeScript check, configured Mypy (19 sources), changed-test Ruff and registry I/O census passed.
• Exact-scope premerge runs before publication; the advisory vocabulary probe has no supported new carriers. Its initial test-path argument was rejected because the advisory only scans production sources; the corrected production scan passed.

Full repository pytest, Linux/Windows CI and live provider deployment are not qualified by these local checks. The runtime maintainer merge gate applies. The future-facing pass kept readiness next to locator publication/dispatch rather than extracting a second lifecycle owner.