[Parity]: [P3] Pre-E1b saves keep 4-wide walkways (migration decision)

Imported from the engineering backlog (_bmad-output/implementation-artifacts/backlog.md, story walkway-width-migration).
Priority P3 (do-first order) | Severity: low | Status: idea | Epic: Classic parity | Type: design-decision | Recorded: 2026-07-12

Divergence from the 1994 original

Pre-E1b saves still carry 4-wide stairs/escalators (canon 8) and the v4->v5 shaft-widening migration deliberately skips walkways. Doubling a flight's width in place is a different re-fit from the elevator +1: the exact-footprint stacking rule means every flight in a stacked run must widen together to the same x/width or the run stops merging (e1b-widths), and an 8-wide fit needs 4 extra clear columns. If legacy-width walkways read as a problem in practice, extend upgradeV4toV5's approach run-wise (widen a whole stacked run or none of it); otherwise leave stored widths trusted, as today.

Start with _bmad-output/implementation-artifacts/backlog.md and the walkway-width-migration story, then inspect upgradeV4toV5 and the e1b-widths stacking rule. Determine whether the migration should handle stacked walkway runs or continue trusting stored legacy widths; done means the migration decision and its behavior are clearly established.