Fix flaky test_read_timerange: neutralize the row-cleaner during the test

[kavehtoyser]

Root cause (confirmed)

clean_database() (daeploy/_service/db.py:208,213) is the only code path in the package that deletes rows, and it re-reads DAEPLOY_SERVICE_DB_TABLE_LIMIT on every call. When a clean runs with a short time limit — the "1seconds" that the db_limit_second fixture sets — it deletes the oldest rows as they age past the limit.

If such a clean runs while test_read_timerange is reading, the table shrinks between reads, so a wider time window can return fewer rows than a narrower one — exactly the observed assert 200 == 195 / 191 / 183 / 175. Demonstrated directly: clean_database() with a 1-second limit wipes a freshly-written 200-row series (200 → 0).

This is why the earlier attempts missed it — the mutation is a delete, not a write-drop (841d194 unique timestamps; the invariant rewrite) or a stale snapshot (the ENGINE.dispose() attempt).

Fix

Pin a huge DAEPLOY_SERVICE_DB_TABLE_LIMIT ("36500days") for the duration of the test via monkeypatch (auto-restored), so any concurrent clean_database is a no-op for this test's data. With deletion ruled out, all 200 rows persist and the meaningful == 200 filtering assertions hold deterministically.

Note

This makes test_read_timerange hermetic against the cleaner. The underlying why does a clean run mid-test (a leaked periodic clean / event loop or test-ordering interaction across the SDK suite) is a broader test-isolation question worth a separate look, but neutralizing the sole deleter fixes this flake at its mechanism.

Verification

Couldn't reproduce locally (load/timing dependent), so CI is the verifier. Test + the db-limit tests pass locally across repeated runs; black + flake8 clean.

🤖 Generated with Claude Code