Fleet leases are never reclaimed after TTL expiry; an expired lease blocks re-acquire

[Regis-RCR]

Summary

A fleet lease outlives its own TTL. Acquire one with a short ttl_seconds, wait
past expires_at, and it stays state: "granted". The expiry never triggers a
reclaim. A second agent that asks for the same scope lands in state: "requested"
and waits there, instead of being granted the lease that should already be free.

Environment

• memtrace 0.6.11
• macOS (Apple Silicon)
• Embedded MemDB, fleet tools called over the MCP transport

Steps to reproduce

1. Acquire a lease with a short TTL:
   fleet_acquire_lease(repo_id, agent_id: "agent-A", scope: ["sym_x"], ttl_seconds: 3)
   The response is state: "granted" with an expires_at about 3 seconds out.
2. Wait well past the TTL (for example 25 seconds).
3. Check the lease:
   fleet_preflight(repo_id, touched: ["sym_x"]) still lists the lease as
   state: "granted", with expires_at now in the past.
4. From a second agent, acquire the same scope:
   fleet_acquire_lease(repo_id, agent_id: "agent-B", scope: ["sym_x"])
   returns state: "requested" (queued behind the stale holder), not granted.
5. Re-check much later: a lease can still be granted about 10 minutes past its
   recorded expires_at.

Observed

• Expired leases linger as granted. No expired state transition is observed.
• A re-acquire of an expired scope is blocked (requested) until an explicit
  fleet_release_lease or an engine restart.

Expected

After the TTL elapses, the lease should become reclaimable (released or expired)
so another agent can acquire the scope. Today the only recovery is an explicit
release, which a crashed or forgetful holder will never issue.

Impact

One holder that crashes, or just forgets to release, blocks the scope for every
other agent. There is no automatic recovery path back to a usable lease.

Note

Fleet intents behave differently here. A published intent does drop out on its
TTL: it disappears from node state once the window closes. The TTL mechanism
clearly works for intents, so the gap is specific to leases. Aligning the two
would resolve this.

[blocksorg]

Mention Blocks like a regular teammate with your question or request:

@blocks can you add technical details to this issue?
@blocks make the following changes ...
@blocks create an issue from what was mentioned in the following comment ...
@blocks explain the following code ...
@blocks are there any security or performance concerns?

Run @blocks /help for more information.

Workspace settings | Disable this message

[Alex793x]

Thanks for the precise repro — this was exactly as reported, and worse than it looked. Three stacked problems, all fixed in v0.6.17:

1. No read-time TTL enforcement. Acquire and preflight trusted the lease's recorded state and never consulted expires_at, so an expired holder kept blocking its scope. Both now treat expiry as a read-time predicate (the same contract intents already had — your note that intents expire correctly was the key hint).
2. A resurrection loop. The periodic cross-process sync re-loaded the persisted copy of the lease — which still said granted — every few seconds, overwriting the local expiry transition. That's why a lease could show granted 10 minutes past expires_at. The loader now coerces past-expiry leases to expired before they ever reach the registry.
3. No promotion on expiry. Only an explicit release promoted queued requests. TTL expiry now promotes the best queued request exactly like a release does, and queued (requested) leases themselves carry a patience TTL so they can't queue forever behind a crashed holder.

Net effect: your repro now grants agent-B's acquire as soon as agent-A's TTL lapses, with no explicit release and no restart. Covered by regression tests for each of the three layers.