fix(recall): cold pool selects by demonstrated reuse, not by self-rated importance

[MXAntian]

The cold pool produces the "oh, I just remembered something" surface: when a recall comes back short, 25% of the time it adds 1–3 rows that are old, untouched, and still worth seeing.

"Still worth seeing" was implemented as importance >= 8.

What that gate actually did

Measured on a 9301-row library: the term excluded 441 of 1124 eligible rows — and the excluded set was led by the single most-recalled memory in the database.

access_count	importance
1879	5	most-recalled row in the pool, excluded
721	7	excluded
634	7	excluded
604	7	excluded
529	7	excluded
495	7	excluded

The gate was doing the opposite of its stated purpose: it filtered out the rows with the strongest evidence of being worth remembering, because someone typed a number when writing them and never revisited it.

importance is 89% saturated at >= 7 across the library, so as a selector it carries almost no signal — and where it does discriminate, it discriminates wrong.

What replaces it

Nothing — the decay floor already does this job, on earned signal.

decay_score is w(age) * reuseBoost(access_count), so a row cold for 30 days only still holds decay_score >= 0.3 if it was reused heavily. Measured on the same library, every row reaching the pool had access_count >= 8, average 135.

Selecting by reuse is what "still important" was always trying to approximate. The proxy was sitting right there; the code used a self-report instead.

Pool: 683 → 1124, gaining exactly the rows with the best track record.

Also

• split the query out as selectColdPoolCandidates so it's testable without fighting Math.random() and ORDER BY RANDOM()
• rebuilt idx_mem_surface_pool. Its old definition led on importance and was partial on importance >= 8; with that term gone from the query, SQLite could no longer use it and would have fallen back to a scan. Now leads on last_accessed, which is what the query range-filters.

Verification

Red-then-green checked properly rather than assumed. With importance >= 8 restored, exactly the one assertion that matters fails — the other five stay green, so they aren't accidentally coupled to it:

✗ a heavily reused memory is eligible even when its importance is low
✓ a high self-rating still gets in — this widens the pool, it does not invert it
✓ the staleness cutoff still holds
✓ the decay floor still holds — it is the real relevance filter
✓ excluded rowids are honoured so the surface cannot repeat a hit
✓ take caps the result size
FAIL: 5 passed / 1 failed

Full suite after the change — all green: cold-pool 6 · recall-contract 14 · ranking-importance 5 · anchor-pinned 4 · level-migration 10 · supersede-shrink 24 · recall-endpoint 17 · query-rewrite 6 · hooks 12.

Risk

The pool grows ~65%, so any single row's odds of being drawn fall about 40%. If the felt experience becomes "it keeps surfacing irrelevant things", that means the decay_score >= 0.3 floor is too loose for this library — tune the floor, don't put importance back.

Stacks conceptually with #36 (same theme: signals that measure the author's intent rather than the system's behaviour). Branched off main independently; CI hunks don't overlap.