[Bug]: [P3] Statistical boarding misses crowd riders: attendance floors can never become hotspots

Review deferral from the #465 origin-accumulator build (/gds-code-review Edge Case Hunter, 2026-07-17). The dispatcher's boarding block counts only the statistical waiting estimate; individually routed crowd riders are excluded by design, and accumulateWaiting deliberately keeps attendance venues (cinema, party hall, wedding hall) out of the estimate because their visitors place real hall calls. Two consequences now surfaced by the origin readouts:

• A tower whose evening rush is a floor-10 cinema shows no hotspot marker on floor 10, the Simulate origin clause names other floors, and Auto-tune's staging aim points elsewhere, while the same shaft's car-load-based demand ring DOES see those riders, so two readouts in one dialog disagree.
• Staff hall counts are not decremented on board, so a service car re-arriving at an unanswered staff call re-tallies the same waiting staff, inflating that floor's origin share on a service shaft (pre-existing for carLoad; the tally makes it player-visible).

Fix direction: feed real crowd boardings into the tally (a small hook where Crowd riders enter a car, or decrement staff hall counts on board), keeping determinism (counting only, no RNG, no behavior read-back). Spec §17's origin bullet records the limit.

Review lane: /gds-code-review.

Start in the dispatcher's boarding block and trace how accumulateWaiting feeds the origin readouts, using the #465 origin-accumulator review in /gds-code-review as context. Inspect the Crowd boarding hook and staff hall count handling, then compare hotspot markers, Simulate origins, Auto-tune staging, and car-load demand rings. Done means real crowd boardings are reflected consistently without RNG or behavior read-back, including staff-call re-arrivals, as limited by Spec §17.