Publish each cycle's store, named for the cycle

[RISCfuture]

A store built on a Mac is only useful to the app if the app can fetch it.
This publishes one per cycle to R2, beside the terrain the same bucket
already serves, and confirms afterwards that what went up can be read
back.

Generation stays on Linux, in NavDataDistribution, where it already runs
daily. This job transcodes what that publishes, which is the whole reason
it needs macOS: SwiftData does not exist on Linux. Two pipelines
generating from the FAA separately would drift, and the drift would only
show up in a cockpit.

Artifacts are named for their cycle and each manifest states the window
it is effective for. There is no "latest" pointer, because a mutable one
cannot say which cycle is current and a stale one is indistinguishable
from a fresh one. It also gives the client somewhere to fall back to: a
cycle whose publish failed leaves the previous one in place, still
carrying its own expiry, rather than a hard 404 for four weeks.

The manifest is uploaded after the store it describes, so a client that
finds a manifest can rely on the store being there.

The job is idempotent — a cycle already published costs two HTTP requests
and stops — so running it daily is how a missed publish gets picked up
rather than waiting for the next cycle.

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_01471376Uhug2TYZN8RDFGtq

---

_{Stack created with GitHub Stacks CLI • Give Feedback 💬}

🤖 Generated with Claude Code

https://claude.ai/code/session_01471376Uhug2TYZN8RDFGtq