fix(desktop): order retained agent events by the relay's own comparator

[wpfleger96]

Agent system prompts, models, and thinking/effort settings revert on their own when more than one Buzz build shares an identity against the same relay. Agent configs sync as NIP-33 replaceable events (30175 definitions, 30176 teams, 30177 agent instances) resolved last-write-wins on created_at, and every desktop boot re-signs whatever its local store holds with a timestamp guaranteed to supersede the relay head. A stale store therefore launders old content into a winning head at every launch.

This is the first of two PRs. It fixes the ordering primitive the rest of the fix builds on; the boot decision pass that stops the laundering follows in the second.

Pending local intent outranks ordering

pending_sync = 1 marks durable local intent — an edit the user made that this device has not published yet. retain_inbound_event now checks for a pending row before any timestamp or event-id comparison, and returns a distinct Deferred outcome that mutates nothing.

A newer created_at is not evidence of newer intent. The laundering vector above mints events at monotonic_created_at = max(now, head + 1), so every laundered revert arrives strictly newer than the edit it reverts. Resolving inbound events by timestamp alone therefore handed the win to precisely the untrusted input: a strictly newer event cleared pending_sync and patched personas.json, destroying the unpublished edit before any arbitration could see it.

Callers in commands/personas/inbound.rs gate on Applied, so neither non-apply outcome reaches disk. Deferred stays distinct from Skipped so the second PR can tell "lost the ordering compare" from "still owes arbitration."

Accepted tradeoff: until the boot decision pass lands, a pending row shadows genuinely newer remote edits for its coordinate. A normal flush clears the flag within seconds, and an edit that can still be reconciled is worth more than one that cannot be recovered.

The ordering bug

For non-pending rows, the retention cache and the relay disagreed about which of two same-second events is the head.

replace_parameterized_event (crates/buzz-db/src/lib.rs) breaks an equal created_at by lowest event id — it rejects an incoming event when created_at == accepted_ts && incoming_id >= accepted_id. The desktop cache skipped every equal-timestamp inbound event instead. Nostr timestamps are seconds-granularity, so this collision is reachable in normal use, and once the cache held a head the relay disagreed with, every later disk-vs-head comparison inherited the error.

retain_inbound_event now applies the relay's own rule to non-pending rows.

Trusting the ordering key

event_id is stored as a real column rather than reparsed from raw_event on every compare, and it is always derived from an event that parsed and cryptographically verified — never read from the JSON's self-asserted id field. A legacy row whose stored bytes do not verify keeps event_id IS NULL and is treated as unorderable: the retained row stands and nothing is decided from a fabricated key. Handing such a row a self-asserted id would let it win a tie it should lose.

RetainedEvent::pending / ::inbound replace the hand-built struct literals at all 13 call sites. Every event-derived field is read from the single event passed in, so a row built through them cannot carry an event_id describing different bytes than its own raw_event — the ordering key and the payload cannot drift apart.

Schema migration

baseline_event_id and baseline_content are added alongside event_id; they are unused here and carry the provenance the second PR's decision table reads.

The migration is additive and crash-safe. A cheap read-only pragma_table_info probe decides whether anything is missing; only then does it open a BEGIN EXCLUSIVE transaction, re-probe inside the lock, and apply the ALTER TABLEs together with the event_id backfill. Two processes opening the same database concurrently are safe by construction — the loser waits on the write lock, re-probes, and finds nothing to do. A crash mid-migration rolls back whole, so a column can never exist with its backfill half-applied.

Behavior deliberately unchanged

Interactive save paths keep force-publish semantics, and the boot reconcile still re-signs past the retained head. Those are the second PR's subject. Nothing here changes what gets published — only which of two same-second events the local cache considers current.

Related: this is the state-model half of the config-revert fix; the boot barrier, decision table, writer-pinned relay seam, publication gate, and parked-conflict surface land in the follow-up PR against this branch.