Sync can double-count copilot usage at the receiver — spans are sent once, but reconciliation output changes #988

codeburn sync push (opt-in) flattens every served call into one OTLP span (collectUnsentCalls → buildOtlpPayload), records each deduplicationKey in the sync ledger, and never sends that key again. Span identity is also derived from the same key (deriveSpanId). The whole pipeline therefore assumes a served call is immutable: same key, same value, forever.

Copilot's serve-time reconciliation (#946) is the first producer of served calls whose values and roles change between passes while their keys stay stable. Sent once and never corrected, they double-count at any receiver that sums tokens/cost or counts spans as requests. Local reports are unaffected — every local surface re-reconciles per pass; this is exclusively about what leaves the machine.

Two failure modes

1. Residuals shrink after they're sent. A residual serves the part of a rollup leg its store rows haven't covered yet, under a stable key (copilot:<sid>:shutdown-residual:<model>:<leg>). Concretely: a leg records 10,000 input tokens; at push time 4,000 are covered by rows, so the receiver gets row spans (4,000) plus a residual span (6,000) — correct at that moment. The remaining rows then land: locally the residual retires to 0, but the receiver keeps the 6,000-token residual span forever (its key is ledgered) and receives the new row spans (6,000). Remote total: 16,000 for a 10,000-token leg.

2. Pairing state flips after a row is sent. A store row synced while unpaired is a behavioral call — one real request. If its journal-side per-turn call appears later (a recovered or resumed session), pairing marks the row supplementary locally, but the already-ledgered row span is never revisited, and the journal call syncs as well. The receiver counts two requests for one.

What's new vs pre-existing

• Pre-existing: spans have never equaled requests — shutdown rollup calls have always synced as one span per (session, model) leg — and the CLI reports raw span counts as calls ("Synced N calls", src/sync/cli.ts). Mislabeled, but stable: pre-feat(copilot): read per-request input/cache from session-store.db #946 every synced value was immutable, so the ledger model was sound.
• New with feat(copilot): read per-request input/cache from session-store.db #946: mutable serve output (shrinking residuals, flippable row roles) behind an append-once ledger — the double-counting above.

Possible shape (needs design)

1. Mark supplementary spans (e.g. ai.supplementary_accounting) so receivers can assign them zero request weight. Marking alone is insufficient — under the append-once ledger the marker's value is race-dependent.
2. Give mutable reconciliation output an identity compatible with send-once semantics: value-versioned keys (a superseding residual re-sends and the receiver keeps the latest), or exclude the mutable classes (residuals, and possibly rollups) from sync and let receivers derive them — filtering supplementary rows outright is not an option, since it would erase recovered usage from the receiver's ledger.
3. Relabel CLI counts as records/spans, or report behavioral calls separately.