Queued live usage is dropped after duplicate account consolidation

[mastertyko]

Problem

A live rate-limit snapshot can be captured for duplicate local account D and remain queued while identity reconciliation consolidates D into canonical account C. Reconciliation reparents existing history and deletes D, but the delayed live-usage consumer still attempts to append with account_id=D.

On SQLite this deterministically fails the usage_history.account_id foreign key. The serving-safe consumer logs the failure and drops the already-captured snapshot, leaving routing and dashboard usage stale.

Reproduction

1. Create canonical C and duplicate D in the same account slot with the same upstream ChatGPT account identity.
2. Publish a primary/secondary live snapshot while D is the selected local account.
3. Complete normal identity consolidation so existing children move to C and D is deleted.
4. Consume the queued snapshot.
5. Observe a stale-D foreign-key failure or a dropped snapshot instead of history under C.

Required invariant

An already-captured live snapshot must survive duplicate-account consolidation:

• prefer the captured local owner while it still exists;
• otherwise use the captured upstream identity only when it resolves to exactly one current account;
• preserve shared-workspace ambiguity instead of guessing;
• protect the selected owner through persistence;
• commit every represented window together under one owner, or roll back all of them.

Scope

This should not change account consolidation policy, queue overflow/coalescing, retry behavior, API schemas, or database schema. It should cover all HTTP/SSE/WebSocket publication taps and include deterministic stale-local, valid-local, and upstream-only regressions.

Related: #1731 and the live-usage portion of #1732 explored identity normalization, but the focused consolidation race still requires owner resolution and persistence in one protected transaction on the current base.