fix(desktop): stop agent config reverts from stale-store laundering

[wpfleger96]

Agent system prompts, models, and thinking/effort settings revert silently when more than one Buzz build shares an identity against the same relay. Agent configs sync as NIP-33 replaceable events (kind:30175/30176/30177) resolved last-write-wins on created_at, and every desktop boot re-signs whatever its local store holds at monotonic_created_at = max(now, head + 1). A stale store therefore launders old content into a winning head at every launch.

This PR fixes both halves: the ordering primitive that cleans up the retention cache, and the boot decision pass that stops the laundering before it can publish.

Part 1 — Ordering

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 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 decision pass can tell "lost the ordering compare" from "still owes arbitration."

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.

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.

Schema migration

baseline_event_id and baseline_content are added alongside event_id; they carry the provenance the decision pass 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 — the loser waits on the write lock, re-probes, and finds nothing to do.

Part 2 — Boot decision pass

Root cause

The laundering vector exists because boot reconcile re-signs the stale store's content at monotonic_created_at, minting events that are definitionally newer than the edits they revert. created_at cannot arbitrate this: the value is manufactured by the reconcile, not observed. No ordering rule can fix it.

The barrier arbitrates on provenance instead. A baseline records what this install last agreed was published at a coordinate. With no baseline, the install cannot show it ever agreed to anything there, so neither its content nor its timestamps are evidence of intent about the relay's state — the pending row must be withheld until the user resolves the conflict or a future boot with a baseline can arbitrate cleanly.

Decision table (decide)

Four ordered gates:

Gate	Condition	Outcome
A	Positive tombstone evidence	Forward to deletion arbitration
B	No baseline, live head present	Park — withhold, surface conflict
C	Queued deletion vs head timestamp	PublishDeletion or Defer
D	Queued edit vs baseline projection	Publish, StampBaseline, or Defer

Gate ordering is load-bearing: gate C's timestamp compare is sound only because gate B already excluded every store that would win it spuriously (the manufactured-timestamp path).

Both publication gates are enforced independently, because a coordinate's live record and its queued tombstone occupy different primary keys and the flush loop reads them independently. The live gate is default-deny over the decision set, so a variant added later is withheld until deliberately admitted.

Evidence

• Head lookups — exact per-coordinate {kinds, authors, #d, limit:2} queries. A transport failure becomes LookupFailed, never Absent, so a flaky network cannot masquerade as a deletion.
• Tombstone scan — one per-owner paginated kind:5 walk. #a is post-filtered server-side, so absence is claimed only from a page shorter than the limit. The scan runs once per boot and yields evidence for all coordinates in one pass.

Composed regression (Will's bug)

test_stale_store_with_no_baseline_cannot_revert_a_newer_head and test_no_baseline_store_withholds_both_the_record_and_its_tombstone exercise the exact scenario: a second install, no baseline, stale disk, live head. Gate B parks it; the flush loop suppresses both the live record and its tombstone row.

The composed regression path runs through the real run_decision_pass/gate enforcement path, not a mock, verifying the full decide → apply_gate → get_pending_sync composition.

Known limitations

On relay deployments that route historical reads through a read-replica pool, head lookups and the tombstone scan read best-available rather than writer-consistent. A replica that has not yet replayed a write answers absence in the dangerous direction. The exposure window equals replica lag (normally single-digit seconds) and requires the coincidence of an agent-config write followed immediately by a boot-time barrier read from behind the lag. The barrier's per-decision tracing line surfaces this if it fires in the wild. Re-adding a writer-pinned read opt-in to the protocol is a small standalone relay PR reversible on observed evidence.

Deferred

Explicit conflict resolution surface (Step 6 / V3.6) — follow-up work, not in this PR: a conflict UI backed by a get_blocked_coordinates query and push-local / accept-remote commands.

A coordinate parked by the barrier (publish_blocked = 1) stays parked for the remainder of the session unless the user actively edits it: every user-initiated save or tombstone calls retain_user_intent_event, which clears publish_blocked so the edit publishes in-session. An edit-free session on an install that was parked at boot will not publish that coordinate until the resolution surface ships. This is the correct polarity for dev-build collisions (the scenario this PR closes) — a stale build that takes no explicit action stays silent. It also affects a legitimate second install where the user has not yet made an edit on that machine; the workaround there is to re-save the agent in the app, which clears the gate and publishes the local version.

The support path for silent parks is the barrier's per-decision tracing line (buzz::config_sync), which logs every Park decision with coordinate, kind, and reason, and direct SQL (UPDATE persona_events SET publish_blocked = 0) against the retention DB. The follow-up delivers a conflict UI with push-local / accept-remote actions, clearing publish_blocked and stamping a baseline atomically per coordinate.

[wpfleger96]

🤖 Closing without merge — direction change, not a defect.

This client-side protection is superseded by the relay-side migration in #4593 and its follow-up slices: relay-enforced predecessor CAS stops the timestamp-laundering resurrection at admission, including from stale binaries — the one property no client-side design can have. The detailed use cases, surface inventory, and regression scenarios from this work have been handed off to that effort.

The branch duncan/agent-config-revert-fix is retained as the reference implementation (review-complete, CI green at tip). If the relay rails slip or the reverts become intolerable in the interim, this reopens as-is.