Compression policies still drift finish-to-start; pin them to the phase grid to finish #3012's deconfliction #3035

#3012's fix (PR #3024) pins the hourly continuous-aggregate refresh policies to a fixed 15-minute phase grid, which ends their finish-to-start drift. Compression policies are the other half of the convoy pairing that issue documents, and they remain unpinned: add_compression_policy is called with a schedule_interval but no initial_start, so every compression job keeps TimescaleDB's finish-to-start scheduling and drifts through the hour by its own runtime each cycle.

Why this is a real residual and not a theoretical one

• The Collector store-writes are cancelled by the store's own CAGG refresh and compression: a lock convoy on query_store_stats #3012 convoy head was compression queuing an AccessExclusiveLock behind a long-running refresh's AccessShareLock on the same hypertable, convoying every collector store-write behind it.
• On the production store measured 2026-09-05, all compression jobs report fixed_schedule = f. The one hand-staggered compression job holds near its hand-set minute only because its runs are typically seconds long — drift is proportional to runtime, and a run that finds a day's chunk eligible takes minutes, not seconds.
• A same-day live read caught the pairing one coincidence away from re-forming: a compression job fired inside the drifted heavy-refresh window and missed a convoy only because that particular run had nothing eligible (0 s) and that particular refresh ran light (194 s versus its 864 s measured heavy cycle). Two favourable rolls, neither guaranteed.
• With refreshes pinned by Narrow the hourly refresh window and phase the refresh family across the hour (#3012) #3024 and compression drifting, the overlap recurs on a slow lap: each compression job wanders the hour and periodically crosses each fixed refresh slot, spending hours-to-days inside a window before drifting out.

Proposed shape (mirror #3024's mechanism)

1. A compression slot on the same grid, clear of the four refresh slots — the hand patch's choice of :52 is measured precedent.
2. initial_start on add_compression_policy (which sets fixed_schedule = true), anchored forward the way the refresh policies anchor.
3. Extend the converge-on-startup sweep to compression jobs: select jobs whose schedule differs from the desired phase/fixed-schedule state, alter_job each with the same per-job failure isolation.
4. Same identity rule as Narrow the hourly refresh window and phase the refresh family across the hour (#3012) #3024: key on the hypertable, never a job id.

Open design question to settle in the PR: whether all compression jobs share one slot (they compress different hypertables, so they do not contend on locks with each other — but ~70 simultaneous compression starts is an IO consideration), or whether they phase across a second grid offset from the refresh grid.

Interaction to preserve

ConvergeCompressionScheduleAsync already exists (#1778) and converges schedule_interval only; the new phase converge must compose with it rather than fight it — one function owning both properties is likely the cleaner end state.

Follow-on from #3012 / PR #3024; the live evidence base is recorded in that issue's comment trail.