hw harness: stage3 D3.7 still asserts pre-#37 teardown-on-disconnect — contradicts its own 'window persists (owner design)' check

[aradanmn]

Found during the PR #82 docked validation (2026-07-15).

Since 6adab75 (#37) a controller disconnect deliberately does NOT tear down the slot — the instance is preserved so the player can rejoin (watchdog reaps only on process/window death). Stage3 was partially updated: it PASSes "D3.7 P2 instance window persists after disconnect (owner design)" — but the same section still asserts:

• D3.7 slot 2 inactive after disconnect (timed out, 15s) — state correctly kept active: true
• D3.7 P1/P3/P4 reposition to 3-up after disconnect — no reflow happens by design; all four windows correctly stayed in their quad cells

Live behavior confirmed by operator: P2's game kept running, P1/P3/P4 stayed controllable and isolated, no slot re-shuffle; on re-plug, slot 2 reactivated in state and reclaimed the SAME slot (no #61 new-slot grab in this scenario) — only gameplay input couldn't reattach, the documented #62 static-bind limitation awaiting the #38 uinput proxy.

Fix: rewrite D3.7's asserts to the post-#37 contract (slot stays active, windows stay put) and drop the 3-up reflow expectations for the disconnect case.

[aradanmn]

Re-confirmed on hardware — HW-2, 2026-07-22 (4-up docked). Live controller-disconnect test (BT-disconnected P2's DS4):

• Log: CONTROLLER_REMOVE → slot 2 controller disconnected — instance PRESERVED (no teardown).
• State: slot 2 stayed active:true with its window (wid 25165831) for the full watch; all 4 slots stayed active (no cascade).
• Geometry: slot 2 held its quad cell (640,0 640x360), window_manager logged 'skip reposition (no flicker)' — no reflow.
• Operator confirmed: P2's window persisted, no re-tiling.

Exactly the post-#37 sticky-slot contract. PR #100's D3.7 rewrite validated.