[Bug][P3]: a theatre screen half flush between two theatres still chains them into one unit

Deferred from the /gds-code-review of the TDT round-trip fidelity fixes (2026-07-31), Edge Case Hunter layer.

mergeParts now splits a merged cluster by horizontal connectivity as well as by floor window, which fixed the case where two flush recycling centers fused into one 40-wide unit. The inner split reuses the same sameBuilding predicate, which includes the theatre-only screenTouch rule (a screen half flush against a hall half on the same floor merges). So the case the docstring already flagged survives: two independent theatres built flush, where one's screen half abuts the other's hall half, still land in one component and import as a single double-width cinema, losing a theatre.

Pre-existing, not introduced by that change. The width-mismatch report line flags the result to the player. Fixing it needs a way to tell which hall a screen half belongs to, which the format may not carry: worth measuring on the Wine harness against a real save that has two flush theatres before writing code.

Story id: tdt-part-merge-screen-chaining

Start with mergeParts, its docstring, and the sameBuilding predicate, then reproduce the case on the Wine harness using a real save containing two flush theatres. Determine whether the format carries enough information to identify each screen half's hall before choosing an implementation. Done means the two theatres import as separate units without regressing the recycling-center split.