[Feature]: [P3] Elevator config UI (schedule strip, car response, per-floor stop list)

Imported from the engineering backlog (_bmad-output/implementation-artifacts/backlog.md, story elevator-config-ui).
Priority P3 (do-first order) | Severity: n/a | Status: idea | Epic: Classic parity | Type: feature-request | Recorded: 2026-07-08

Problem / motivation

Gated: needs a spec; UI half of the elevator-scheduling epic. Owner observation 2026-07-08 from the real game (harness screenshot). The 1994 elevator inspector is far richer than ours: a per-shaft dialog with a WD/WE weekday-vs-weekend schedule toggle across a 24-hour clock-icon strip, Waiting Car Response (how many floors closer an idle car must be before it answers, stepper), Standard Floor Departure (seconds to wait before departing, stepper), a scrollable serviced-floors list with per-floor SHOW On/Off (including setting the shaft's starting/base floor from the UI), and Simulate / OK actions. Build an equivalent elevator config dialog. This is the front-end for elevator-scheduling (owner tiebreak: FULL PARITY, behavior AND UI) and should round-trip the same TDT schedule bytes; keep this row as the UI/UX design surface (dialog layout, mobile adaptation of the clock strip + floor list) and let elevator-scheduling own the sim/dispatch model. See ui-layer-diegesis for the DOM-chrome vs engine-drawn split.

Start with _bmad-output/implementation-artifacts/backlog.md and the elevator-config-ui story, then read the elevator-scheduling and ui-layer-diegesis references. The issue needs a UI specification before implementation. Done means an equivalent elevator configuration dialog with the schedule strip, response and departure steppers, serviced-floor controls, starting-floor setting, Simulate/OK actions, mobile adaptation, and round-tripping the same TDT schedule bytes.