Windows-only flake: backfill_stubs_preexisting_tables_on_reopen fails on table-name assertion

Start with hyperdb-mcp/tests/table_catalog_tests.rs at the backfill_stubs_preexisting_tables_on_reopen test and its table-name assertion. Trace the catalog reopen path to determine why alpha is missing on the Windows CI leg, then verify the root cause and that the test passes reliably without simply rerunning the failed job.

Summary

backfill_stubs_preexisting_tables_on_reopen failed on the test (windows-latest) leg during CI for #267, a PR whose diff touches only hyperdb-mcp/tests/daemon_tests.rs.

hyperdb-mcp\tests\table_catalog_tests.rs:429:5
assertion failed: names.contains(&"alpha".to_string())
test backfill_stubs_preexisting_tables_on_reopen ... FAILED
test result: FAILED. 21 passed; 1 failed

Why this is not #267

• #267 modifies one file, daemon_tests.rs, and this failure is in table_catalog_tests.rs.
• Both tests #267 modifies passed on that same Windows leg (daemon_idle_timeout_shuts_down_daemon ... ok, daemon_heartbeat_prevents_idle_shutdown ... ok; that binary reported 52 passed; 0 failed).
• The assertion is about table names present after a catalog reopen and has no timing content.

Platform

Windows-only so far. The same test (windows-latest) leg passed on the v1.0.0-rc.2 release commit c9bacf2 (job 101457433522), so this is intermittent rather than a persistent break on that commit.

Please root-cause rather than re-run

Two cautions from recent experience in this area.

The failure record is perishable. Re-running a failed job rewrites the run conclusion, so the evidence of this failure disappears and historical flake counts become a lower bound. This was demonstrated live: an earlier run containing a real failure now reads success after a re-run.

Two "flakes" in this repo recently turned out to be real defects, not timing. slow_health_watchdog_reaps_hyperd_after_child_timeout was caused by validate_hyperd_process identifying the engine with ps -p <pid> -o comm=, which on Linux reads the main thread name — and hyperd renames its main thread to hyperdMain, so the guard rejected the very process it existed to reap (200/200 on Linux). And daemon_idle_timeout_shuts_down_daemon (#267) was a measurement-reference bug, where the test captured its Instant::now() after DaemonState::new() had already started the idle countdown. In both cases the obvious timing explanation was wrong.

So a backfill/reopen assertion failing on one platform is worth reading as a possible ordering or persistence bug in the catalog-reopen path before being written off as flaky.