--backfill-rollups converges hierarchical dailies to raw's oldest, but the arming gate is source-relative: hourly-tier policies stay held on healthy stores after DONE #1798

Observed (DARLING01 lab box, dev @ a0d83d7)

A full --backfill-rollups run completed and printed DONE, including the operator contract line promising that the next start reads N/N retention policies in place, N armed, 0 held paused pending backfill. The restart instead printed:

TimescaleDB: 16/16 retention policies in place, 14 armed, 2 held paused pending backfill

with these WARN lines naming the held pair:

Retention policy for procedure_stats_hourly created but HELD PAUSED - procedure_stats_daily does not yet cover everything it holds, so arming could drop history no rollup has.
Retention policy for query_stats_db_hourly created but HELD PAUSED - query_stats_db_daily does not yet cover everything it holds, so arming could drop history no rollup has.

The gate is right to refuse. The verb's completion claim is what's wrong.

Root cause

Two different notions of "covered" disagree:

• TimescaleSupport.RollupViews pairs every rollup — including the hierarchical dailies — with its RAW hypertable, and the verb's convergence test (DarlingCliCommands, reached = finalFloor <= after.RawOldestUtc) converges each rollup to raw's oldest row.
• The arming gate for an hourly-tier retention policy is source-relative: the daily must cover everything the hourly holds (daily min(bucket) <= hourly min(bucket)).

query_stats_db_daily, procedure_stats_daily, and query_store_stats_daily are hierarchical continuous aggregates (FROM collect.<x>_hourly, not raw). On a healthy store — raw purges armed, raw only a few days deep — the hourlies legitimately hold far more history than raw. Backfilling the dailies "to raw's oldest" leaves daily min(bucket) newer than hourly min(bucket), so the hourly-tier gates stay held even though the verb's own criterion ("every rollup now covers its raw table") is satisfied.

Why the original #1759 remediation profile doesn't hit this

On a store whose raw purges were held (the profile the verb was built for), the hourlies are a subset of raw's span. Converging both tiers to raw's oldest satisfies the hourly-on-daily gate by construction (day-floor <= hour-floor of the same instant), so 0 held is genuinely reached there. The gap only bites stores whose raw purges have already armed.

The sharp edge

Any hierarchical daily added after its hourly, on a store with armed raw purges, enters a hold that nothing in the product can clear: the daily cannot materialize the pre-raw region from raw (those rows are purged — the data exists only in the hourly), and the verb never targets the hourly as a floor. That's a permanently-held retention policy plus unbounded hourly growth, remediable only by a manual refresh_continuous_aggregate over the hourly's span. Same invisibility class as #1759, one tier up.

Fix sketch

Per-rollup source floor:

• Carry each rollup's source relation alongside the raw mapping (hourlies -> raw table; hierarchical dailies -> their hourly view). RollupViews already exists as the single drift-proof list; extend it rather than adding a parallel one.
• The verb's convergence target for a rollup becomes its source's oldest row/bucket; the completeness-by-construction invariant becomes floor <= source_oldest. Preflight, newest-first slicing, and the refuse paths are already per-view and carry over unchanged.
• The DONE contract then genuinely implies 0 held on every store shape.
• The read-side RetentionTierRouter mapping to raw stays exactly as-is — falling back to raw is correct for routing; this is purely the backfill verb's completion target.

Acceptance rig

DARLING01 is deliberately left in the 2-held state as the live reproduction: after the fix, a --backfill-rollups run there must extend the two dailies down to their hourlies' oldest buckets and the next restart must read 16/16 ... 0 held.