fix(cli): stop set-add-policy erasing the agent profile

[cyberzero000]

buzz channels set-add-policy published a kind:10100 whose content was only
{"channel_add_policy": ...}. The kind is replaceable, and the relay projects
just that one field into a column
(crates/buzz-relay/src/handlers/side_effects.rs) — channel_ids, name,
display_name and respond_to live solely in the event body clients read.

So one policy change wiped the rest of the profile. Desktop's @mention picker
reads channel_ids to decide whether an agent is invocable in a channel, so the
agent disappeared from every channel's picker until an operator republished the
profile by hand.

Now it reads the current profile, merges the field, and republishes.

Three decisions the merge has to get right

Each is a pure function with tests, because getting any of them wrong
reintroduces the wipe.

A result the command cannot fully read is an error, not an empty profile.
parse_stored_profile returns an empty body only when the identity genuinely
has no profile. A body that is not a JSON object is refused rather than
replaced, and so is a result row missing a readable content or created_at —
treating either as absent would republish a single-field profile and cause the
exact wipe this fixes.

The write out-bids the stored copy's created_at rather than tying it.
Db::replace_addressable_event breaks a same-second replaceable tie by lowest
event id, so publishing at now is a coin flip against a peer republishing the
profile in the same second, and a deterministic loss against a copy stamped
later by a skewed peer. Retrying at now cannot win either.

The lead is bounded with headroom under the relay's 900s tolerance. Stamping
stored + 1 is only ever one second ahead of whichever writer produced the
stored copy, so the lead measured against our own clock is just this host's skew
from that writer's — and refusing on a few seconds of it made the command
unusable wherever a peer's clock ran ahead of the operator's. The relay's window
is measured against its clock and this budget against ours, so the two are not
directly comparable: a copy accepted at S when relay time was R proves only
S - R <= 900, and out-bidding it at S + 1 can sit up to 901s from relay
time. The 600s budget leaves room for that overshoot.

Confirming the write

Read-modify-write on a replaceable event has no compare-and-set, so this
re-reads after publishing. duplicate: means the relay took the write and
rolled it back — it arrives as accepted: true, so reading only accepted
reports success for a discarded write.

Comparing the stored head's id to ours is not enough on its own. That read
cannot be pinned to the primary: kind:10100 is global, so the filter carries
neither a channel pin nor an until, which makes it RoutePredicate::Bounded
and lets the relay serve it from a read replica whenever
BUZZ_REPLICA_READ_MAX_AGE_MS is set. That budget bounds how recently the
replica proved its replay position, not whether a write from a moment ago is
visible — so a read issued straight after the publish can legitimately return
the pre-write event.

The relay's own replace rule separates that lag from a real loss: a stored copy
that loses the created_at/lowest-id comparison to the event we just published
cannot have replaced it. So the read-back is classified three ways:

outcome	meaning	result
Landed	our event is the stored head	success, exit 0
Replaced	a copy that beats ours is stored	re-merge onto it and publish again
Unconfirmed	the read cannot see our write, or it failed	success with a warning, exit 0

Unconfirmed is a success because the relay accepted the event and nothing that
could have replaced it is stored. Calling it a conflict instead would republish
a byte-identical event, draw duplicate:, and return exit 5 with
retryable: true for a policy change that was already stored — a caller
treating 5 as "retry me" would loop on a landed write. Its stdout keeps the
documented {event_id, accepted, message} shape with an additive warning key,
the same way the create commands inject a new entity id.

A confirmation read that fails outright is Unconfirmed too, not the command's
error: the mutation has already happened by then, so borrowing the read's error
would report a stored policy change as a network failure.

Exit 5 is still returned when the profile is genuinely replaced out from under
us on every attempt.

The window is narrowed, not closed: a peer publishing between our read and our
write still loses its change, because a replaceable write carries the whole body
and nothing records what we replaced.

Error classification

Profile-read failures keep their CliError variant instead of flattening to
Other. exit_code and is_retryable_error classify by variant, and those
codes are the CLI's agent-facing contract, so flattening reported a retryable
503 as exit 4 / retryable: false and an expired BUZZ_AUTH_TAG as exit 4
instead of 3 — telling an agent to abandon both as permanent.

Deliberately not done

Three things this PR leaves alone on purpose, so a reviewer does not have to ask:

• No --force for a malformed stored profile. The relay does not validate
  kind:10100 content shape (handle_agent_profile is a side effect whose
  failures are only logged), so another client can leave a non-object body
  stored, which this command then refuses. A flag is a wider change than the
  bug warrants; the refusal message now names a recovery path that exists
  (sign a corrected kind:10100 and submit it to POST /events).
• created_at is guarded with content, not separately. One check covers
  the whole unreadable-row case rather than two independent guards for one
  malformed response.
• MAX_PROFILE_PUBLISH_LEAD_SECS stays at 600. The 901s worst case above
  needs a stored copy ~10 minutes in the relay's future plus skew at the exact
  boundary. The constant is fine; only the comment claiming it "sits well
  inside" the relay window was wrong.

Testing

cargo test -p buzz-cli — 375 passed, 0 failed. Twelve new tests.

Mutation-checked, each mutation caught by exactly the test that covers it:

mutation	test that fails
any id mismatch on the read-back is a conflict (the behavior before this fix)	a_read_that_cannot_see_our_write_is_not_a_conflict
flatten every profile-read error to CliError::Other	a_transient_profile_read_failure_keeps_its_exit_code
restore the unwrap_or defaults for content and created_at	a_result_row_we_cannot_read_is_refused_rather_than_treated_as_absent
treat a non-object body as absent	an_unreadable_profile_is_refused_rather_than_replaced
publish at now instead of out-bidding	a_merge_out_bids_the_stored_copy_instead_of_tying_it, a_stored_stamp_past_the_relay_window_is_refused_not_out_bid

cargo clippy -p buzz-cli --all-targets -- -D warnings and cargo fmt --check
clean. just file-size-check clean.

Note

Split out of #5806, which found this while debugging why an agent answered
@mentions in one channel and was silent in another. It stands alone and has no
dependency on the rest of that branch.