unity-drivinglisted

# Driving a Unity game over SDB The `unity` tools drive a running Unity Mono development build over the Mono Soft Debugger protocol (SDB); this skill is the procedure the tool schemas cannot carry. Everything holds for any dev-Mono Unity game; the type names in examples are placeholders (`MyGame.…`), so substitute the target's own. A retail build exposes no SDB port; only a development Mono build is drivable. ## Session lifecycle The first tool that needs the VM attaches on its own, the session persists, and a dropped connection reattaches on the next call, so just call the tool you need. The game is found by the PlayerConnection beacon it multicasts, which carries the debugger endpoint: there is nothing to configure, and every attach resolves that endpoint afresh, so a game restart costs nothing. `status` is the read-only orient step: what the beacon advertises, the endpoint an attach would use, and session state (attached, held suspensions). Everything it reports describes the present, so act on it as read. A game running while `status` reports no beacon means the beacon is not getting through: multicast blocked by a firewall or a VPN interface, or `beaconFault`/`beaconListening` reporting the listen itself impaired. Either way, call `attach` with the game's debugger port. That port governs that one attach, so give it again after any reattach for as long as the beacon still cannot see the game. Rule that out first when `status` also shows a held suspension: a suspended g