fix(test): make UBI fast-seed rung test time-independent (anchor to now)

[SoundMindsAI]

Summary

test_synthetic_ubi_seed_round_trip_hits_rung_3 has been red on main since ~2026-06-28 — a deterministic time-bomb, not an ES flake (my initial diagnosis on PR #623 was wrong; see below).

The test hardcoded seed_anchor_iso="2026-05-29", but classify_rung counts events only within a trailing [now - 30d, now] window (DEFAULT_READINESS_WINDOW_DAYS = 30). Once "now" drifts >30 days past the anchor, every seeded event falls outside the window → count 0 → rung collapses to rung_1, for everyone, regardless of ES health. It surfaced on the 2026-07-11 security PR simply because that was the first CI run past the bomb.

Fix

Anchor the synthetic events to now - 1 day so they always land inside classify's window — matching the real demo paths (demo_seeding.py:1448, seed_meaningful_demos.py:2469), which already anchor at now. This is the only call site that runs the real now-windowed classify_rung against a hardcoded past anchor (the unit tests anchor-relative internally, so they're unaffected).

Diff is two lines of substance: a datetime import and the relative anchor.

How the real cause was found

The first attempt on this branch added a searchable-_count verify + classify retry, on the theory that an ES "name resolution" flake was under-counting the read. CI then reported "verified 640 searchable in ES … got rung_1" — proving the events were present and searchable, so the flake theory was wrong and the count was a window problem, not a presence problem. That scaffolding was reverted; this PR is just the anchor fix.

Test plan

• ruff check + mypy + py_compile clean
• CI backend (contract + integration) — now expected to pass (events land inside the classify window)

Once green and stable, backend (contract + integration) becomes a candidate for a required status check under the new main branch protection.

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request improves the resilience of the integration test test_demo_seeding_ubi_fast.py against transient Elasticsearch connectivity issues on CI runners by verifying that seeded events are searchable before asserting the rung and adding a retry loop for the classification step. The review feedback suggests enhancing error handling in these new additions: first, by catching TypeError when parsing the Elasticsearch response to handle unexpected JSON structures gracefully, and second, by wrapping the classify_rung call in a try...except block within the retry loop so that transient network exceptions do not prematurely fail the test.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[SoundMindsAI]

Review adjudication (Gemini Code Assist)

Both inline comments target the first revision of this branch (a searchable-_count verify + classify_rung retry loop). That approach was reverted after CI proved the failure was a time-window bug, not an ES flake — this PR is now just the relative-anchor fix, so both comments are obsolete (GitHub marks them outdated). Resolving.

#	Location	Verdict
1	retry loop	Obsolete — code reverted
2	ES unexpected-response handling	Obsolete — code reverted