[Parity][P2]: 1994 game reports "No transportation connected" for a room our engine considers served

Observed 2026-07-31 on the Wine harness while validating the elevator built-shaft payload fix (spanned-floor stride).

After re-exporting the owner's 4-star sixseven_14 tower with the corrected stride, the tower loads and renders healthy in the retail 1994 game: shafts draw, tenants move in, Pop climbs past 640. But the room inspector on an office at floor 63 reads "No transportation connected", while our engine reports two standard shafts stopping at that floor (elevatorStandard@x188 and @x267, confirmed by walking the deserialized tower).

Not yet established whether this is:

• a file-fidelity gap (something the game needs in order to bind rooms to shafts that we do not write, most likely the §11 lobby/reachability table we emit as a blank 0xFF region, see #310), or
• a legitimate 1994-vs-our-engine reachability difference for a tower designed under our rules (walkable-corridor or two-ride modeling), which would be an engine parity question rather than a format one.

Next step: build a minimal harness tower where a single shaft serves a single office, confirm the inspector says connected, then add distance/gaps until it flips. That isolates whether the binding is positional, table-driven, or recomputed.

Story id: tdt-1994-room-reachability

Start with the Wine harness and build the minimal tower described: one shaft serving one office, then add distance and gaps until the retail inspector changes state. Compare the result with the deserialized tower and inspect the blank §11 lobby/reachability region referenced in #310. Done means identifying whether the mismatch is file fidelity or engine reachability behavior.