bd record assignee/status spontaneously reverts to open/unassigned despite active heartbeated lease

Bead gc-64ioik in city gascity-cloud has repeatedly had its bd record's assignee/status fields spontaneously revert from in_progress/logist back to open/(empty), despite an active, correctly-heartbeated gt-bd lease held by the logist role's live session throughout. This has now happened at least twice, confirmed independently:

1. ~2026-09-11T11:29Z: gt-bd check-lease returned "нет lease" (no lease) for a lease that should have been active — recovered via gt-bd claim + bd update --claim.
2. Most recent (reported ~2026-09-11T16:1x UTC by the logist role): the bd record's assignee/status fields themselves reverted to open/empty, and a --unassigned ready-query then picked the bead up as apparently-new unclaimed work — a more serious symptom than #1, since it risks a different role or session claiming and duplicating work on a bead that's actually already being actively worked. Recovered the same way (gt-bd claim + bd update --claim), restoring in_progress/logist.

Both times the bead had an active human-gate decision pending (owner hasn't yet decided), so the bead was correctly meant to stay in_progress and parked — there was no legitimate reason for its bd state to change.

Suspected mechanism (unconfirmed)

Given this city also runs a stale-lease-dozor that periodically scans for P0/P1 in_progress beads with an expired lease age (we've independently seen it fire correctly-benign alerts for other beads with intentionally-short lease TTLs, e.g. gc-karof.4/gc-karof.7, which legitimately re-heartbeat every cycle) — it's plausible some lease-cleanup or reconciliation path is occasionally treating a bead as abandoned and force-resetting its assignee/status, even when a live session is actively heartbeating it. This is speculation; we have not traced the exact code path, just the observed symptom and recovery.

Environment

• City: gascity-cloud
• Bead: gc-64ioik (P1, in_progress, assignee logist)
• Role observing: logist (self-recovered both times via gt-bd claim <id> + bd update <id> --claim)
• Recurrence: at least 2 confirmed instances within the same ~5 hour window (11:29Z and ~16:1x Z on 2026-09-11)

Impact

Low-to-moderate today (logist caught and recovered both times before any duplicate work happened), but the failure mode — a live, actively-worked bead silently reappearing as unclaimed in --unassigned ready-queries — is exactly the kind of thing that causes duplicate/conflicting work across concurrent roles if not caught.