[Docs][P3]: zero-height elevator shaft payload size is inferred from the span rule, never measured

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

builtShaftPayloadSize sizes a shaft with topFloor === bottomFloor as ONE 324-byte per-floor entry, by extension of the measured spanned-floor rule. That case has never been measured against the real game, and cannot arise from our own exporter (the gather pass drops top <= bottom), so it only matters when reading a corrupt or hand-made save. If the retail game instead writes zero per-floor entries for a degenerate shaft, our reader over-skips 324 bytes and desyncs the rest of the table. The test fixture shares the helper, so no test would catch it either.

Low priority: the 1994 game has no UI for building a zero-height shaft. Resolve it opportunistically the next time the harness is up, by hand-editing a real save's shaft to span one floor and re-reading the game's own re-save.

Story id: tdt-degenerate-shaft-payload

Start with builtShaftPayloadSize and the shared test fixture helper, then use the harness to hand-edit a real save's shaft to span one floor and inspect the game's re-save. Compare the retail encoding for a zero-height shaft with the reader's inferred 324-byte entry size. Done means the encoding is established and the reader and its tests no longer risk desynchronizing the table.