projects update fails on any project older than 15 minutes (CLI head+1 timestamp vs relay drift window) #5665

Summary

buzz projects update (and any other project replacement) computes the replacement event's created_at as head.created_at + 1 (next_timestamp in crates/buzz-cli/src/commands/projects.rs). The relay's ingest path rejects any event whose timestamp is more than ±900s from server time (MAX_TIMESTAMP_DRIFT_SECS, crates/buzz-relay/src/handlers/ingest.rs).

Consequence: updating any project whose head is older than 15 minutes always fails.

Repro (self-hosted relay, CLI built from current main)

$ buzz projects create pr-ts-smoke --repo buzz --name "pr-ts-smoke"
{"accepted":true,...}

# ~2 hours later (or backdate the head to simulate):
$ buzz projects update pr-ts-smoke --description "update on aged head"
{"error":"relay_error","message":"relay error 400: invalid: event timestamp too far from server time","retryable":false}

Even inside the 15-minute window the behavior is off: the replacement is accepted but recorded at head+1, i.e. in the past —

$ buzz projects update pr-ts-smoke --description "update on 52s-old head"
{"accepted":true,...}
$ buzz projects get pr-ts-smoke | jq .created_at
# => 52s older than the wall-clock time of the write

so a concurrent writer using wall clock silently wins LWW against a head+1 writer, and audit timestamps misrepresent when the write happened.

Suggested fix

next_timestamp should return max(now, head.created_at + 1) — strictly after the observed head, but never behind the wall clock. The relay itself already uses exactly this pattern when it authors replacements (now.max(head+1) in crates/buzz-relay/src/handlers/side_effects.rs).

Related: #2876 reports the same head+1-vs-drift-window collision for repos protect set/remove on repos announced more than 15 minutes ago.

PR incoming.