Module lease 

Serverless writer lease (PLAN.md Phase 5 / W6).

Multiple RedDB instances can attach to the same remote-backed database key. To prevent two of them from concurrently mutating the same remote artifacts (snapshots, WAL segments, head manifest), exactly one of them must hold a writer lease. Other instances may still attach as read-only replicas without acquiring a lease.

Wire format

The lease is serialized as JSON under leases/{database_key}.lease.json on the remote backend:

{
  "database_key": "main",
  "holder_id": "instance-uuid",
  "generation": 7,
  "acquired_at_ms": 1730000000000,
  "expires_at_ms":  1730000060000
}

• generation increments every time a different holder acquires the key. The holder stamps its uploads with the generation so a stale writer (whose lease was poached because it expired) can be detected during reclaim by reading the current lease and comparing.
• expires_at_ms is wall-clock millis since UNIX epoch. A holder refreshes it periodically; a contender treats anything past it as poachable.

Atomicity contract

Lease mutation requires backend-side compare-and-swap. Backends advertise this through RemoteBackend::supports_conditional_writes and implement object version tokens + conditional writes/deletes. A backend that cannot enforce IfAbsent / IfVersion fails closed before the instance is allowed to write. This keeps serverless fencing out of “last writer wins” territory.

Structs

LeaseStore

Wraps an AtomicRemoteBackend with lease primitives. The lease object is stored under a deterministic key derived from database_key; the store reads/writes that one key.

WriterLease

One snapshot of who owns the writer lease for a database key.

Enums

LeaseError