feat(start-sdk,start-os): record a retired binding's successor on the host

[MattDHill]

Summary

A URL plugin holding an address for a port a service renumbered has no way to know where the port went, and cannot infer it from the binding's absence: a host being rebuilt one bind call at a time — a restore, a rebind after retire() — passes through the same state, and nothing a package can read separates the two (getStatus carries health and desired state, not install state). The guide's own "Why this cannot be automatic" is the same argument from the OS's side. So the package says it.

• retire_binding takes an optional successor and records the retired port with it in a new Host.retired_bindings map ({ 8333: 58333 }, or { 9090: null } when nothing replaces the port). add_binding and add_binding_range clear the entry when the port is bound again. StartOS itself acts on nothing there.
• MultiHost.retirePort(port, { successor }) passes it through; the existing form is unchanged. The retireBinding effect doc, the guide's Retiring a Host or Binding section, the service-to-service note on a retired dependency, and the 3.0.0 changelog entry describe it.
• Tor is the consumer. fix: park an onion whose port its service stopped declaring, offer it for reuse; 0.4.9.12:6 → 0.4.9.12:7 tor-startos#37 parks a .onion whose port its service stopped declaring and lets the user move it; with this record it moves the address itself. The first packages to pass a successor are the fleet's 0.3.5 conversions that renumbered a port on the same host — Bitcoin Core's peer 8333 → 58333, Nextcloud's main 8080 → 80, and seven more — in their SDK 3.0 bump.

Unit test covers the clearing on rebind; SDK test covers the pass-through. cargo fmt --check and prettier clean. The TS bindings are not in this PR: Host.ts and RetireBindingParams.ts need make start-core-ts-bindings, which does not fit the machine this was written on, so the Generated Artifacts job will fail on drift and upload them; they land as a follow-up commit from that artifact. Not exercised on a box.

Refs Start9Labs/tor-startos#36.

🤖 Generated with Claude Code

[dr-bonez]

Closed: the consumer this was written for is going away.

Under the tor-startos redesign (Start9Labs/tor-startos#38), Tor does not move an onion to a successor port. A disabled binding is left alone, because it is not a deleted one, and a service that stops using a port retires it, which is what clears the onions attached to it. With nothing reading retired_bindings, the record and the successor option have nothing to serve.