compute: delay retracting a dropped export's lifecycle rows [deferred, unsound]

[antiguru]

Deferred. Not ready, and not close to ready. Do not pick this up without reading the blocker below — the two-dyncfg design in this PR does not survive it.

Blocker: delayed retraction is unsound while ids can be reused

The delay retracts an export's rows at a future timestamp while removing its ExportState immediately. Nothing records that a retraction is pending, so a new export with the same GlobalId inside the window inserts a fresh row and the relation ends up holding two rows with the same (export_id, worker_id, event) from different incarnations. That breaks the at-most-once property the relation documents and that test/testdrive/compute-lifecycle-events.td asserts under max-tries=1, and it corrupts any duration a reader computes with max(occurred_at) FILTER (...).

Transient ids are reused because TransientIdGen::new() starts at 1 per process (src/repr/src/global_id.rs:123-129), so a plain environmentd restart — replicas survive and reconcile, transient dataflows are dropped, new generation reissues t1… — collides inside the window.

Non-transient ids can also be reused during reconciliation, so the window is not a transient-only problem. That kills the obvious fix: excluding transient exports from the delay does not make this sound, and the split between compute_lifecycle_retraction_delay and compute_lifecycle_retraction_delay_transient is not the axis that matters. Any future attempt needs to make retraction and re-insertion of the same id ordered — for example a pending_retractions map flushed at the current timestamp when handle_export sees an id whose retraction is still outstanding — before the delay is worth having at all.

Note the base PR is unaffected: it retracts at the drop timestamp, so no window exists in which two incarnations of an id coexist.

Two further findings, unaddressed

• An unclamped compute_lifecycle_retraction_delay panics the replica in ts_at's expect("must fit"). There is a lower clamp to the logging interval but no upper one, and ALTER SYSTEM SET reaches it.
• The delay makes the relation carry rows whose export_id is absent from mz_compute_exports_per_worker for up to the delay. The ontology description was written before dropped existed and still implies a lifecycle row means a live export, and the design doc and the testdrive orphan check disagree about whether an orphaned row is expected.

---

Original motivation

The lifecycle log retracts an export's rows the moment it is dropped, so an object's history vanishes with the object. That loses exactly the episodes worth looking at: a dataflow dropped before it hydrated, or one whose hydration is the reason someone opened the log. A short-lived dataflow can also come and go inside one introspection interval and leave no trace.

Part of CPU-226.

What is in the diff

Two commits on top of #38403: the retraction delay with a dropped stage and two dyncfgs, and an unrelated design-doc correction about catalog_server_explain.slt.

The dropped stage is the part worth keeping from this attempt. Without it a lingering row says only that an export reached some stage, not whether it still exists, so "hydrated but never written" cannot be told apart from "dropped before it wrote".

The storage reasoning also stands independently of the soundness problem: a transient export exists per peek and per subscribe, so at eight workers and two hundred peeks per second a five-minute window holds around 1.4 million rows, hundreds of megabytes, while a user object is dropped by DDL and a thousand drops inside the window is under ten megabytes. Whatever replaces this will still need to treat those two populations differently, just not by delay alone.

[linear-code]

CPU-226