flaky: dash/TestSpendSurvivesRowEviction is red for the first 10 hours of every month (fixture backdates across the month boundary)

[amiddavid]

dash/TestSpendSurvivesRowEviction fails deterministically, not intermittently, for the first
10 hours of every calendar month. It is failing right now on main (e88f5d8).

=== RUN   TestSpendSurvivesRowEviction
    spend_test.go:43: month-to-date = 7, want 10
--- FAIL: TestSpendSurvivesRowEviction (0.03s)

Cause

spendEvents (dash/spend_test.go:12) backdates its fixture by one hour per session:

base := time.Now().Add(-time.Duration(sessions) * time.Hour).UnixMilli()

The test asks for 10 sessions, so the oldest event is 10 hours old, and then asserts
MonthToDateUSD("t1") == 10.0 — i.e. that all 40 priced requests fall inside the current
month. Run at 07:42 UTC on the 1st, 3 of the 10 sessions land on the previous month's last
day, MonthToDateUSD correctly excludes them, and the assertion fails with 7.

Nothing is wrong with MonthToDateUSD or with DropOldestSessionsOfTenant — the fixture is
asserting a property of the clock. It is 3/3 reproducible on main at
e88f5d8, on the current time; it will pass again after 10:00 UTC today.

Severity

Medium. The suite gates every deploy, and this is a hard red for a ~10-hour window each month
(and for the whole of a shorter window in other timezones' CI). It is distinct from the two
load-dependent flakes in #91: those need a saturated box, this one needs only a date.

Fix options

1. Inject the clock into the fixture — build the events from a fixed timestamp that is
   known to be inside the month, e.g. anchor at the 15th of the current month rather than at
   time.Now(). Cheapest, keeps the property being tested intact. Recommended.
2. Assert relative rather than absolute — read MonthToDateUSD before eviction and only
   assert it does not fall afterwards, dropping the == 10.0 precondition. Loses the check
   that the fixture priced what it thought it priced, and that precondition is what makes the
   "did not fall" assertion non-vacuous, so this trades away real coverage.
3. Shrink the backdating — spread the sessions over minutes instead of hours. Narrows the
   window to ~10 minutes a month rather than closing it, and the sessions must stay distinct
   in time for the eviction ordering, so this only moves the bug.

Found while running the full suite to verify PR #138 (which touches neither dash Go code nor
spend accounting); reproduced on unmodified main to confirm it is pre-existing.

[amiddavid]

Already fixed on main. No PR needed — closing.

Verified against current main (79e0716) at 08:04 UTC on the 1st, i.e. inside the window where
this fails, run three times:

guard present: 3 matches for `avail` in dash/spend_test.go
=== RUN   TestSpendSurvivesRowEviction
--- PASS (0.04s)   --- PASS (0.03s)   --- PASS (0.03s)
ok  github.com/rossoctl/context-guru/dash  0.162s

The fix is the month-boundary guard in spendEvents, which compresses the fixture's spacing when less
than sessions × spacing has elapsed since the 1st:

if avail := now.Sub(monthStart); avail < time.Duration(sessions)*spacing {
    if spacing = avail / time.Duration(sessions+1); spacing < 10*time.Second {
        spacing = 10 * time.Second // floor: keep sessions and their turns from overlapping
    }
}

It landed in 1f1ac2b, "Recover accounts broken by #118's config change, and stop hiding it (#144)",
committed 2026-09-01T05:23:40+03:00.

Why three of us reported it as failing on main

Every reproduction ran against a checkout that predates that commit:

who	tested against	pre-guard?
review of #136, #137, #138	e88f5d8	yes — confirmed by git merge-base --is-ancestor e88f5d8 1f1ac2b
the agent on #138	its own checkout	yes
the agent on #136	e88f5d8	yes
me, an hour ago	yesterday's git archive of main	yes (0 matches for avail)

So the diagnosis in the original report was right about the mechanism — a flat 10-hour backdate puts
sessions in the previous month during the first hours of the 1st — and simply described code that had
already been superseded. My own reproduction gave month-to-date = 8, want 10 at 08:03, which is the
pre-guard fixture behaving exactly as described.

And it explains the discrepancy in the review, which reported the suite green while we reported this
failing. The review comments are timestamped 05:29–05:39 UTC and the guard was committed at 05:23 local
(+03:00). The most likely reading is that the reviewer's working tree already carried the guard —
whether from a newer fetch or from the same local work — while the SHA they cited did not. Worth
noting as a process point rather than a fault: a review's cited SHA and its working tree can diverge,
and this is what that looks like from the outside.

Practical note

If this recurs, check grep -c avail dash/spend_test.go before reaching for a fix. Zero means a
pre-1f1ac2b tree, not a live defect.

Related: #91 covers the genuine load-dependent flakes in dash, which are a different thing.