Tell the user what to do when a record's model version is newer than this build

Follow-up to #222, which added modelVersion to every persisted project and draft record and the guard that refuses a record stamped higher than CURRENT_MODEL_VERSION. That guard is deliberately the simple version: assertSupportedModelVersion throws, storage leaves the record untouched on disk, and whatever the caller already does with a failed read is what the user sees. This issue covers making the user's experience of that refusal something other than an unexplained failure.

The scenario is narrow but real:

• A user has not updated in a while and their build is out of date.
• They fetch a project a team member has since saved under a newer schema revision.
• Their build refuses it, correctly — but nothing tells them the fix is to update.

What a user sees today

A newer project disappears from the picker. listProjects logs and skips any record it cannot read, and after #222 a newer record is one of those. The project is simply absent, with the reason only in the log. If it were reached by id instead — the open flow — the refusal surfaces as the generic %interlinearizer_error_load_projects_failed% notification, which says nothing about versions.

A newer draft refusal is silent until the first edit. getDraft throws; useDraftProject logs and falls back to an empty draft, so the editor opens blank with no message. saveDraft then refuses to overwrite the record the read protected, so the first auto-save raises %interlinearizer_error_save_draft_failed% — the right outcome, arrived at confusingly.

Nothing distinguishes "you are out of date" from "this record is damaged." Those two want opposite advice, and the stamp is enough to tell them apart if we know what revisions exist.

Proposed work

1. Name the case in the UI. A distinct, localized message for a version refusal, separate from the generic load/save failures: this record was written by a newer version of the extension, and updating is what opens it.
2. Keep a newer project visible in the picker rather than dropping it, marked as needing a newer version and not openable. This is the piece that requires more than a message — listProjects currently has no way to return a record it refused, so it needs a shape that carries "present but unreadable."
3. Check the stamp against what revisions actually exist. If the stored revision is one a released build understands, prompt to update. If it is higher than any revision that has ever existed, the record is corrupt, not futuristic — point at support or the troubleshooting docs instead. This needs a source of truth for "revisions that exist" that an old build can consult, which is the part worth designing before building.

Priority

Low. Nobody has data written by any build yet, and even once they do this needs a schema bump plus a version skew inside one team to trigger. Filed so the decision is recorded rather than rediscovered when the second revision lands — at which point item 3's data source has to exist before the revision that needs it ships.

Start by reading the model-version guard from #222 and its callers: listProjects, getDraft, useDraftProject, and saveDraft. Trace how refused records reach the picker, editor, and localized notifications, then resolve the source of truth for revisions that exist. Done means newer supported records remain visible but blocked with an update message, while impossible revisions receive corruption or troubleshooting guidance.