Keep nav data and user data in separate stores

[RISCfuture]

Nav data is replaced whole every cycle. Until now it shared a file with
the scenarios and NOTAMs the pilot wrote, so replacing it meant deleting
rows out from under them — the destructive import this work exists to
remove. They are two files now: nav data read-only at NavData, and
everything the pilot authored writable at UserData, opened together as
one container so a fetch still finds either.

Nav data is read-only because a store the app cannot write is a store the
app cannot leave half-written. The importer opens its own writable
container instead, and the app recovers from a nav store that will not
open by discarding it — it is a downloaded file, and a bad download must
not cost the pilot the use of the app. The user store keeps trapping,
since nothing works without it.

Both stores are opened through the same pair of configurations, always.
SwiftData records the whole container's schema in every store it opens,
so a nav store written by a container of a different shape reads back as
one needing migration — and migrating a store opened read-only fails
outright, which is how this was found.

An install predating the split has its scenarios carried across and the
old store retired. NOTAMs are not carried: they never outlive a data
cycle, and the schema-version bump makes the next launch reload nav data
anyway. For the same reason the importer no longer deletes them — a
successful load clears them afterwards, through the store they now live
in.

A UI test's airports are seeded through a writable container before the
app opens the store, the same way a downloaded cycle will be.

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