Make a stalled draw wait observable (B-36)

_wait_for_next_block had no timeout, no log, and no audit entry: a
connection that stopped advancing the tip left a round silently frozen
in "drawing" with nothing in /admin to explain why. Log progress
periodically, write a draw_stalled audit entry past a threshold (a few
block-time multiples), and surface the wait via a new Round.drawing_started_at
column, exposed as draw_waiting_since in GET /rounds/current.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

BUGS.md

@@ -1,16 +1,17 @@
 # Known bugs
 
 A second full-codebase audit on 2026-07-27 found **25 further issues** (4 critical, 6 high,
-7 medium, 8 low), listed below as B-33 … B-49. B-25 through B-35 are fixed (see "Previously
-fixed" below) — no Critical-severity finding remains open; the other 14 are High/Medium/Low.
+7 medium, 8 low), listed below as B-33 … B-49. B-25 through B-36 are fixed (see "Previously
+fixed" below) — no Critical-severity finding remains open; the other 13 are High/Medium/Low.
 The 139-test suite was green at the time of the audit, so none of these were caught by existing
-coverage — every fix lands with a regression test (the eleven fixes so far brought the suite
-from 139 to 198).
+coverage — every fix lands with a regression test (the twelve fixes so far brought the suite
+from 139 to 200).
 
 The recurring pattern across the open findings is worth stating once: the code is rigorous
 about the failure modes that have actually been hit, and silent about the ones that have not.
-The payout phase is now fully recoverable; the "drawing" phase (waiting on a block) still has
-no equivalent resume-after-restart or stall visibility (B-36).
+The payout phase is now fully recoverable; the "drawing" phase (waiting on a block) is now
+observable (B-36) but still has no equivalent resume-after-restart — see "Known gaps / TODO"
+in [CLAUDE.md](CLAUDE.md).
 
 For limitations that are accepted by design rather than bugs (single-shared-token admin auth,
 single-process assumptions, no user-facing history, etc.), see "Known gaps / TODO" in
@@ -20,18 +21,6 @@ single-process assumptions, no user-facing history, etc.), see "Known gaps / TOD
 
 ## Medium
 
-### B-36 — `_wait_for_next_block` waits forever, with no timeout and no visibility
-
-`rounds/scheduler.py:158-161` loops until a higher block arrives. No timeout, no log, no audit
-entry. If the connection dies in a way that stops the tip advancing, the round sits in
-`drawing` indefinitely and **the admin panel shows nothing at all** — just a frozen state with
-no explanation.
-
-**Proposed fix.** Log progress periodically while waiting, and past a threshold (a few
-multiples of the 120s block time) write a `draw_stalled` audit entry so it surfaces in
-`/admin`. Surface the wait in `GET /rounds/current` too (it already returns
-`chain_tip_height`; `draw_waiting_since` would make the stall self-evident to users).
-
 ### B-37 — Displayed balance and spendable balance diverge, and the error does not explain it
 
 After a bet the change is unconfirmed, so `cached_balance_sats` ≈ 0 while the UI shows
@@ -184,9 +173,10 @@ already does.
 - **B-33** — `POST /auth/login` had no rate limiting, so a password could be brute-forced against an enumerable username list
 - **B-34** — password change/reset didn't invalidate already-issued JWTs, so a stolen token survived a change meant to lock it out
 - **B-35** — API timestamps round-tripped as naive datetimes, so the frontend parsed them as local time instead of UTC
+- **B-36** — a stalled draw wait had no timeout, no log, and no audit trail, so a frozen round showed nothing in `/admin`
 
 See git history for the fix-by-fix breakdown (commits `f13f685`, `50a43ae`, `933760e`, and the
-B-28/B-29/B-30/B-31/B-32/B-33/B-34/B-35 fixes). Suite grew from 139 to 198 tests over the eleven.
+B-28/B-29/B-30/B-31/B-32/B-33/B-34/B-35/B-36 fixes). Suite grew from 139 to 200 tests over the twelve.
 
 A full-codebase audit on 2026-07-26 (commit `d4e0974`) found 24 bugs across every Python
 module under `app/`, both static frontends, and the Docker/Caddy deployment — 5 critical,