[Parity]: [P3] Auto-floor charge on elevator extension (watch-only, by design)

Imported from the engineering backlog (_bmad-output/implementation-artifacts/backlog.md, story auto-floor-extend-charge).
Priority P3 (do-first order) | Severity: low | Status: open | Epic: SimTower parity | Type: review-deferral | Recorded: 2026-07-13

Divergence from the 1994 original

Watch-only, by design. From the v1.25.0 auto-floor-build (1) review (gds-code-review, Blind Hunter). The elevator-extend auto-floor (behavior 1) folds the auto-created floor tiles into the existing per-floor extend charge (ECON.transportFloorCost, $5,000/shaft-floor) rather than billing floor.cost per tile on top, so a shaft-floor is one priced action (matching the 1994 "no separate floor-build step"). This is deliberately asymmetric with the FLOOR-tool bridge, which charges floor.cost per gap tile. It is not an exploit: extending a shaft is strictly MORE expensive per floor than laying the tiles by hand ($5,000/floor vs $500/tile), so nobody floors a tower via elevators to save money. Itemizing the floor charge cleanly (without a negative-money edge in the budget-clamped extendBill drag path, which knows only a single flat per-floor cost and can't tell sky floors from built ones) is disproportionate to the ~$500/tile amounts. If the owner wants the extend to itemize its floor cost, add a non-mutating Tower count of the tiles a resize would create, fold it into extendBill's per-step budget, and charge it in both editor extend paths.

Start with _bmad-output/implementation-artifacts/backlog.md and the auto-floor-extend-charge story, then inspect the existing extendBill flow, ECON.transportFloorCost, and the two editor extend paths mentioned in the issue. This is currently watch-only; if the owner chooses to proceed, done means a non-mutating Tower tile count is incorporated into budget handling and both extend paths charge consistently.