fix(console): stop the message list livelocking under sustained refresh (BACKLOG #17)

[wshallwshall]

Fixes BACKLOG #17 — the flaky test_monitor_observes_engine on Windows CI. It was never a timing flake.

Root cause

MessagesPanel._apply() cleared the in-flight guard, re-fired any refresh latched during the read, and returned before rendering — discarding the snapshot as "superseded":

self._loading = False
if self._drain_pending():
    return              # <-- snapshot thrown away

Whenever a caller refreshes faster than a read completes there is always a latch waiting when the read lands, so every snapshot was discarded and the table never rendered. Permanently stuck, not slow.

Measured with a probe: 391 reads served, 0 rendered, over 20s.

Why the previous two fixes couldn't work

Both assumed a timing flake. No deadline escapes a livelock, so neither 10s → 30s nor reruns=2 could ever have helped.

It passes locally because the engine processes the message before the panel connects, so the single initial refresh() in _build_inner renders it and the polling path never runs at all. A loaded runner lost that race about a third of the time.

The fix

Render first, then drain. Costs at most one read of staleness — the drained refresh re-reads the current filters and renders again immediately, so the list still converges on the latest filter — but it can no longer starve itself.

This is a real GUI defect, not just a test problem: sustained refresh pressure wedges the message list in the harness too.

Tests

• tests/test_console_messages_refresh.py (new). MessagesPanel had no test file at all, which is how this shipped. A unit form (a latched refresh must not discard the render) and a sustained-pressure form.
• test_monitor_observes_a_message_that_arrives_after_connect (new). Writes the message after connect so the initial snapshot is empty by construction — exercising the livelocked path deterministically instead of depending on losing a race.
• _spin now takes one deadline shared across both waits instead of two independent 30s budgets, names the condition, and reports elapsed plus the status label (which carries poll failed: …). Four CI failures produced only condition not met within timeout, identical from either wait, and revealed nothing.
• reruns=2 removed. It was added for this bug, would now only mask the next one, and makes this fix unmeasurable — a masked failure looks exactly like a working one.

All three new tests were verified to fail against the previous ordering.

Note on what is not evidence

CPU saturation does not reproduce this — the old code passes 3/3 under full-core load. Load stress is not a valid gate for it; the after-connect ordering is. Recording that so it isn't reached for next time.

Local: 300 passed, 15 skipped across the harness/console suites; ruff check/format clean in CI's scope.

🤖 Generated with Claude Code