A method receipt's UUIDv7 already stamps its commit; add the start, stamp the ledger capture and the run, and read performance over time from the store #910

Epic: #449 — Eventing, narration, and the control plane · Feature: #504 The three OpenTelemetry signals

What the owner wants

Times should be at the provider method level. I should be able to examine traces and see changes in performance over time.

What the record already holds, found 2026-09-22

Every provider-method receipt on the recovery stack commits with a transaction_id that is a UUIDv7 (pkg/op/receipt.go:391), and a UUIDv7's first 48 bits are a millisecond timestamp. The receipt's own filename is the moment the trace was written. Decoding the two receipts that bracket #904:

So the store can already show that the 137 provider calls took 30 ms on both days and that the three minutes sat between the last commit and the write -- the ledger capture. Nobody had read it that way; the regression was found by a human noticing the wait and the fix proven with a stopwatch.

The gap

1. A commit is an end, not a span. A method's duration today is the distance to the previous commit, which is right only while execution is sequential; flow.gather runs its body concurrently by design. Each activation needs its start recorded, so a method's time is its own.
2. The capture has no stamp. The 180.8 s above is inferred from the filename. The ledger capture -- the phase that hid The ledger snapshot digests every Active resource, twice per run: a discovered directory boundary such as ~ is Merkle-walked (1.7M files) at the end of every deploy, silently, and the walk is discarded #904 -- should record its own start and end, as should the run.
3. There is no reader. The decoding above is a script. A command over the run index (writ reconcile already folds receipts by graph) should line up runs of one plan by date and show the run's duration, the capture's, and the per-method durations, slowest first, so a change in performance is a column.

The OpenTelemetry trace signal (#504) is the natural shape: a span per run, per subgraph, per activation, per capture, landing in the document the run already writes, with the UUIDv7 commit stamp kept as the span's end.

Not in scope

Narration during the run is the control plane's second piece and its own work; this issue is the record and the reading of it.

Acceptance

• a receipt records a start and an end for the run, for the ledger capture, and for every activation; the method's transaction_id stays the commit stamp
• a command that reads only the store compares runs of one plan by date: run duration, capture duration, per-method durations slowest first
• the 2026-09-21 / 2026-09-22 pair is a test fixture: two receipts, and the comparison names the capture as the 180 s

Plan and design documents