The archival claim, checked against the storage it names

The archival claim, checked against the storage it names The README said cold assets stay discoverable and the tiering path was asserted against SeaweedFS and a fake store with a controllable clock — the wire protocol and the state machine, neither of which can prove an actual `RestoreObject`. That gap was documented in the status block a few hours ago. It is now closed instead. Against real S3 in `ap-south-1`, on a bucket created for the run and deleted after it: **20 cases passed, 0 skipped**, and a Glacier restore completed in **76.7 seconds** and served back the original bytes. The zero matters as much as the twenty — a skip here would mean the store reporting itself incapable against a backend that plainly is not, which is a capability-detection bug rather than a fact about AWS. `mise run check:aws` reproduces it, and is deliberately the one gate outside `check:all`: it bills a real account and waits on a real restore, so it is something a person runs on purpose rather than something a pre-push sweep does to them. Its docs say to point it at a throwaway bucket, because Glacier bills a 90-day minimum on every object it touches and deleting the object does not cancel that. **The nightly loses its schedule and keeps `workflow_dispatch`.** Not because it is wrong — it is the same suite that just passed — but because a scheduled run cannot borrow an SSO session, and static IAM keys are a decision rather than a step. Left scheduled, it would fail every night in a public repository for a reason no reader could tell apart from "the archival tests fail". The cron is commented with what to set to bring it back, rather than deleted.