seal: nothing renews an archival timestamp, and LTA is now the default

[LKSNDRTMLKV]

#293 chose LTA and said "target LTA with a renewal drain". The level shipped; the renewal drain does not exist, and no open issue owned it until this one.

The state

#325 delivered the signal and closed on it — cades::archival_freshness, served on GET /api/v1/dpp/{dppId}/seal, in the evidence dossier and by odal seal status:

• notArchived — no archival timestamp, kept distinct from lapsed because a B-LT seal was never promised long-term protection;
• current { expires } — the authority's certificate is still valid;
• lapsed { expires } — it has gone;
• unknown — present and unreadable, deliberately not current.

That was the right call and it was explicitly "a signal, not a verdict". Nothing consumes it. A grep for renew across the workspace finds only the continuity-snapshot tier.

Why it is now a live commitment rather than a future one

LTA is the default on main, and the local backend advertises and emits archive timestamps. So every seal this workspace produces already carries one, and every one of them will eventually lapse — silently, into a field an operator has to go and look at.

An archival timestamp is what keeps a seal verifiable after its signing certificate expires and after the algorithms under it weaken, which for a retention-locked passport is the entire point. ETSI's long-term profiles handle the expiry by re-timestamping before it happens: a new archive timestamp over the old, forming a chain. The window between current and lapsed is the only chance to do that without an outage, and it is exactly the window nothing is watching.

What a drain needs

#293 listed most of it:

• Find seals approaching expiry. archival_freshness already reports expires, so the readback exists — what does not is a query. The seal audit (0038, seal_drain::audit_seals_once) already walks every stored seal in batches and is the obvious place to notice, rather than a second walk over the same estate.
• Apply a fresh timestamp. Worth checking whether the provider exposes re-timestamping as a distinct operation or only as a full re-seal — the two have very different costs, since a seal is bought per digest.
• Decide what happens to the old envelope. A re-timestamped seal is new bytes over the same passport. PROTECTED_PATCH_FIELDS and the publish JWS hash-pin both have opinions about rewriting a sealed passport, and feat(seal): report a seal's issuer and device leg #322's repair route already had to answer a version of this.
• Decide the lead time. Too late is an outage; too early spends money on seals that had years left.

The order this sits in

#330 first, probably. It is currently possible for an archive timestamp to be reported as protecting a seal it has nothing to do with, because archival_token compares nothing against the enclosing signature. Building a renewal drain on top of a freshness signal that can be about the wrong token means renewing on the strength of a number that may not be ours.

Not urgent, with the usual asterisk

No node here holds a QTSP credential, so every archive timestamp in existence is one the local backend generated with an authority it also generated — nothing with legal weight is lapsing. The asterisk is that the clock starts with the first real seal, and a drain is not something to design under time pressure.

Related: #293 (the decision) · #325 (the signal, closed) · #330 (the token may not be ours) · #322 (the audit walk that would host this)

[LKSNDRTMLKV]

Unblocked by #349. The dependency named here — "building a renewal drain on a freshness signal that can be about the wrong token means renewing on the strength of a number that may not be ours" — is resolved: cades::archival_freshness now refuses a token it cannot tie to the signature, so the expires a drain would read is about this seal or it is not reported at all.

What that changes for the design sketched above:

• "Find seals approaching expiry" is now a sound query rather than a plausible one. ArchivalFreshness::Current { expires } means this seal's protection runs to that date.
• A new state matters operationally. A seal whose archive timestamp cannot be tied to it now reports unknown, and that is not a renewal candidate — it is a corruption finding, and the seal audit's territory rather than a drain's. Worth deciding which surface owns it before either does, or both will.
• The local backend now emits conformant archive-time-stamp-v3 tokens with an ats-hash-index-v3, so a drain can be exercised end to end here rather than only against a provider nobody can currently buy from.