Upstream #2876: metadatos de repo congelados a los 15 min (bind + protect inutilizables)

[A-PachecoT]

Contexto

Tracking local del bug upstream block/buzz#2876
(abierto 2026-07-25, sigue OPEN). Nuestra reproducción independiente + el hallazgo
compuesto están en
este comentario.

El defecto: build_updated_repo_announcement
(crates/buzz-cli/src/commands/repos.rs) firma toda mutación de anuncio de repo con
created_at = existing.created_at + 1, pero el relay valida contra reloj de pared con
ventana ±900s (MAX_TIMESTAMP_DRIFT_SECS, crates/buzz-relay/src/handlers/ingest.rs).
Como el avance es de +1 y nunca alcanza al presente, la falla es permanente:
pasados 15 minutos desde la última edición, los metadatos del repo quedan congelados
para siempre. Afecta a repos bind, repos protect set y repos protect remove.

Por qué nos importa operativamente: combinado con block#2877 (el tag
buzz-channel es el ACL de git) y block#2326 (no hay forma de borrar un anuncio
de repo), un repo anunciado sin --channel queda permanentemente single-pusher y sin
recuperación in-band. Hay exactamente una ventana de ~15 min en la creación para que
el binding quede bien, para siempre.

Regla operativa mientras el upstream no lo arregle

Siempre buzz repos create --channel <uuid> en el mismo comando. Nunca crear
primero y bindear después. Si un repo quedó sin binding, no hay arreglo: hay que
anunciar uno nuevo con otro --id.

Esto ya está registrado en handbook/infrastructure/buzz/BITACORA.md.

Criterios de aceptación

Este issue se cierra cuando una de estas ocurra:

• Upstream mergea un fix a buzz repos protect set and repos protect remove are rejected by the relay's timestamp drift check on any repo announced more than 15 minutes ago block/buzz#2876 y lo pinneamos en nuestro railway-deploy.
• Parcheamos el CLI en el fork (max(now, existing + 1) en next_created_at)
  si el upstream se demora y necesitamos protección de ramas mutable.

Verificación

Contra el relay vivo, con un repo anunciado hace más de 15 minutos:

buzz repos protect set --id <repo-viejo> --ref refs/heads/main --push owner --no-force-push
# hoy:     {"error":"relay_error","message":"... event timestamp too far from server time"}
# fixeado: {"accepted":true,...}
buzz repos protect list --id <repo-viejo>   # debe mostrar la regla

Guardrails

• No ampliar MAX_TIMESTAMP_DRIFT_SECS en el relay — la ventana de ±900s es una
  defensa contra replay, no el bug. El defecto está del lado del CLI.
• Si parcheamos el fork, mantener la propiedad monotónica que el comentario original
  del código protege (que un writer demorado no pise una edición intermedia); no
  reemplazar por now a secas.

Scope + refs

• crates/buzz-cli/src/commands/repos.rs — build_updated_repo_announcement
• crates/buzz-relay/src/handlers/ingest.rs — MAX_TIMESTAMP_DRIFT_SECS (solo lectura)
• Upstream: buzz repos protect set and repos protect remove are rejected by the relay's timestamp drift check on any repo announced more than 15 minutes ago block/buzz#2876 · relacionados No shipped client can emit the buzz-channel tag, so only the announcing key can ever push to a Buzz-hosted repo block/buzz#2877, No way to delete a repo announcement (kind:30617): CLI has no repos rm, and Desktop 'Delete project' is owner-gated to keys the app holds block/buzz#2326