[Bug]: [P3] Zero-vs-unsampled conflation in the demand rings: a dead weekend can never warm

Review deferral from the #466 day-split build (/gds-code-review Edge Case Hunter + Blind Hunter, 2026-07-17). The demand accumulator encodes "not yet sampled" as a 0 slot, and sampleElevatorUtil only writes a slot when the sampled load is positive, so a day with genuinely zero traffic (the motivating office tower's weekend) never accumulates a positive sample and its ring never passes the warm-up gate: no ghost, no advice, and Auto-tune never tunes that day's row down from measurement. The day split (#466) made this conflation load-bearing per day. Related drift trap: HourlyByDay always carries both arrays, so "unmeasured" is derived by scanning for positives in two independent places (the dialog's warm() and the engine's measuredDay()); any future consumer that skips the scan treats an all-zero ring as measured.

Fix direction: make "sampled" first-class, for example a per-ring sampled-hours count or bitmask on HourlyByDay (still transient, no serialization), let a sampled-but-zero day warm, draw zero-height demand dashes, and collapse the duplicated warm scans onto the new field. Also resolves the spec §17 "measured zero vs not yet sampled" ghost limit.

Review lane: /gds-code-review.

Start by locating the demand accumulator, sampleElevatorUtil, HourlyByDay, the dialog's warm(), and the engine's measuredDay() mentioned in the issue. Trace how sampled state is currently inferred, then verify that sampled-zero days warm, render zero-height demand dashes, and use one shared sampled-state field without serialization.