perf(signerd): #216 follow-up · bound unbounded per-session self.requests growth #218

Follow-up carved out of #216 / #217 (kept separate as agreed — a perf concern, not the #216 correctness bug).

Problem

self.requests grows unbounded per unlocked session: propose inserts, expire_stale() only flips
status in place, terminal records are never pruned (no remove/retain), and the map is only ever
cleared wholesale on Unlock (daemon.rs). The 200-cap on activity_feed() was masking this. Now
that the INBOX correctly reads the uncapped pending_list() (#217), both pending_list() and
activity_feed() iterate and serialize the full map on every ~2s poll — over a long agent session
that's a growing per-poll frame/serialize cost, and the live-Pending set itself has no admission
bound.

Direction (not a decision)

• Bound the settled tail via a retention/prune policy (keep the newest N settled + all open),
  applied in expire_stale/resolve/execute.
• Optionally bound the live-Pending set via proposal admission (rate-limit / cap concurrent
  open proposals per session).

Hard invariant (from #216)

Never apply a cap to the pending/Pending subset. Any cap on the inbox re-opens #216 (a waiting
approval hidden/unreachable). Only the settled LOG is safe to bound.

Severity: ~P3 (perf/memory over a long session; no wrong trust cue).