fix(api): derive the pool/records TTL from what the query actually costs (#687)

[defenwycke]

Closes #687.

pool/records?window=month could serve an answer up to five minutes stale.

The 300s was not arbitrary — it was sized for a query that no longer exists

The TTL was chosen when the month window measured 7-20s, where recomputing
often would hang the pool page. But that cost is a property of the data,
not the query: the month window's cost is dominated by how many rows of
shares_archive still fall inside it, and the archive stopped being written at
the v56 cutover.

Measured on ghost-vm6, 2026-09-06:

shares_archive rows (total, static)	1,981,755
archive's newest row	18.7 days old
archive rows inside the 30-day window	550,321
live shares rows inside the window	55,760
month query, cold (vm1)	~0.6s — not the ~20s the constant was sized for
live shares only (the limit it converges on)	95ms

The archive is frozen, so in roughly eleven days zero archive rows fall
inside the month window and the query converges on 95ms. Holding a 95ms answer
for five minutes is staleness bought for nothing.

⚠ That decay is a coincidence of the archive being frozen, not a fix — which is
why this PR does not simply lower the constants to today's numbers. They would
be wrong again, in the other direction, in eleven days.

Hold the duty cycle constant, not the interval

adaptive_records_ttl recomputes after 60x the query's own measured duration,
clamped to a 5s floor and the existing per-window ceiling. The measured cost is
stored in the memo alongside the answer.

• month, today: ~36s instead of 300s
• month, after the archive ages out: ~6s
• a node whose query regresses: backs off by itself up to the 300s ceiling —
  the protection the fixed ceiling was really providing, now automatic
• duty cycle: capped at 1/60 (under 2%) whatever the query costs

The cost is measured after the error arm returns, so a fast failure cannot be
recorded as a cheap success and drive the TTL down.

What this deliberately does not do

• It does not make the query cheaper. Ranking by rarity means
  reverse_hex(share_hash) over every row — a function of the column, so no
  index can serve the ORDER BY. The structural fix is an indexed display-order
  column plus a backfill of ~2M archive rows; that is a migration, not this PR.
• It does not rank by difficulty instead. Tested and refuted: difficulty
  is the assigned vardiff target, not the achieved one. Four distinct hashes
  in the current month window carry 620606.037971378 to fifteen significant
  figures, so ordering by it returns an arbitrary one of the four rather than
  the rarest. The handler's own winning_assigned_diff naming agrees.

Tests

Four new tests, each naming the behaviour rather than the constant. They were
mutation-checked: reverting adaptive_records_ttl to the old fixed-TTL
behaviour fails a_cheap_query_is_not_cached_for_the_window_ceiling and nothing
else, so the suite encodes the fix rather than restating it.

https://claude.ai/code/session_01Td1vvfowptTTnu88qG2iym