editor-main-threadlisted

# Editor Main-Thread Guidelines Everything the bridge does per tick runs on the editor main thread: `XUUnityLightMcpBridgeBootstrap` subscribes to `EditorApplication.update` and drives the heartbeat (2 s), the request pump (0.5 s), lifecycle and scenario ticks. Any blocking call there is a frame stall the user feels as editor lag. The bridge being invisible in the editor is a product requirement, not an optimization. --- ## 1. Never Sleep on the Main Thread `Thread.Sleep` in tick-reachable code is forbidden. A sleep-based retry converts rare contention into periodic frame stalls (a 5×20 ms retry loop in the atomic writer stalled heartbeats whenever the host poller held `bridge_state.json` — caught in user review, 2026-07-11). On contention, **fall back instead of waiting**: immediate retries, then degrade to the legacy behavior the host side already tolerates (see atomic-ipc-files skill rule 3). `tests/test_atomic_ipc_contract.py::test_no_main_thread_sleeps_in_editor_package` sweeps the whole package; `XUUnityLightMcpGameViewUtility` (on-demand screenshot settling) is the single allowlisted pre-existing exception — do not widen the allowlist without the same on-demand-only justification, and prefer converting it to a frame-deferred capture. ## 2. Blocking I/O Needs a Bound - Synchronous socket sends from the main thread must set a send timeout first: `TcpClient.SendTimeout` before writing a response (`TryWriteResponse` uses 5000 ms) — a dead peer with a full send buffe