Replay record: fallback shorter than known closes, and non-bearer confirmations shrink it

What

Two ways last_moment_usable leaves the replay record (#50) shorter than it could be, found by @jarvis9443 reviewing #53. Both apply to every tracked assertion, OneTimeUse or not, which is why they are filed against the record rather than fixed there.

1. The fallback is dominated. An assertion acceptance never bounds gets replay_ttl (600s default); one valid until 9999 gets the day cap. The strictly worse input gets the 144× shorter record. Measured: confirmations {C1: this ACS, NotBefore an hour out, no close} + {C2: this ACS, close at T+4h} record 600s, while C2 alone records ~14460s, leaving [T+600, T+14460), inside the IdP's stated window, unprotected; acceptance past T+1h is unbounded either way, so the longer record dominates. The proposed one-liner, usable_until == nil taking the day cap, would settle both, but it also retires the documented meaning of replay_ttl, so it needs deciding here, with the option's docs.

2. Non-bearer confirmations count. confirms_here ignores SubjectConfirmation@Method, so a sender-vouches sibling with no close, next to an ordinary 30-minute bearer confirmation, drops the record from ~30 minutes to 600s. Profiles 4.1.4.2 expressly permits other confirmation methods beside the required bearer one, so this shape is in-profile and inside shipped windows: the strongest item here. Fix: only bearer confirmations weigh in last_moment_usable. Whether they should weigh anywhere else is #45 (Method is parsed and checked by nobody, including at acceptance).

Not in scope

The full-zone fail-open path was weighed on #53 and stays: refusing there is a lockout lever and evicting unprotects another user's record; the ERR names the zone and README's sizing paragraph is the remedy.