Build the nav-data store on a Mac instead of on the aircraft

[RISCfuture]

The app spends minutes assembling this store on the pilot's device, once
a cycle, before it can be used at all. DownloadNASR can build the same
store in under a minute and publish it, turning that wait into a
download.

Measured against the current cycle: 29,287 airports and 654,785
obstacles, 84 MB as a store and 18 MB compressed, against 14.7 MB for the
property list the app builds it from today. The download grows by a fifth
and the import disappears.

It is built by transcoding a dataset that has already been published,
rather than going back to the FAA for it. The store is then a pure
function of the payload the app falls back to, and cannot drift from it.
It is written through the same NavDataStoreWriter the app's own import
runs, for the same reason.

VACUUM INTO writes the result, rather than a copy. Core Data journals
ahead, so a store copied out from under a writer leaves its most recent
rows in the write-ahead log beside it — and a store published without
that sidecar opens perfectly and reads as empty.

The built store is then reopened read-only through the app's own pair of
configurations and its rows counted, because a store this binary can
write but the app cannot open is the failure worth catching in a build
rather than in a cockpit.

Each cycle gets a manifest named for it, stating the window it is
effective for, the schema shape it was built against, and the size and
digest of the store. There is no "latest": a mutable pointer cannot say
which cycle is current, and a stale one looks exactly like a fresh one.

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