mobile: AppStore.openFile is a shared mutable slot, prone to races between concurrent file loads #17

What

Why (motivation)

PR #15 found and worked around one instance of this: FileViewerView's async syntax-highlighting had to add path-identity guards specifically because a superseded file load can still overwrite the shared openFile slot after a newer load already completed. The guard fixes that one call site, not the underlying shared-state design, so the same class of bug can resurface anywhere else that reads openFile.

User impact

A user quickly tapping between two files in the file tree could briefly (or, in rarer timing, more than briefly) see the wrong file's content displayed under the right file's title, which is confusing and could lead someone to misread or misjudge code they think they're looking at.

Cost of inaction

Every future feature that reads or writes openFile inherits this same race and has to rediscover and re-guard against it individually, the way this PR just did.

Acceptance criteria

• Loading a file returns its content directly to the caller (or is keyed by path+ref in a cache) instead of being communicated only through the single shared AppStore.openFile property.
• Opening file A, then quickly navigating to file B before A finishes loading, always ends with B's content on screen -- never A's, even if A's network request happens to resolve last.

Screenshots

(none)

Links

• (none)