App Studio follow-ups after #477 #480

Follow-ups from the maintainer re-review of #477 (App Studio, ADR 0006 milestone 1). All of them concern developer builds only; none blocks the merge of #477.

UI-thread work in the studio (M3 remainder)

• Renderer::event still calls validity() → dev_mode::tag_valid / grants_all without the grant cache, taking developer mode's lock twice per signal, timer and frame event while a studio.render job runs. Cache validity per developer-mode generation, as studio::apps::granted does.
• installed_apps() is cached for two seconds; a miss re-reads, re-hashes and re-admits every developer install (up to 16 × 2 MiB) on the UI thread, reached from draw code and the launcher. Refresh the installed set when installs or developer mode change, or on a worker, not on a timer.
• open_bundle takes developer mode's lock four times and, on a changed owner, does an fsync'd claim_data write. Move that I/O off the UI thread.

Tests (M2)

• The owner-claim and uninstall tests exercise the helpers (claim_data, uninstall_at); add one that goes through install() for the wipe on a changed owner, and one for "uninstall refused while an instance is open".

Owner records (N1)

• data/<id>.owner.json can collide with an app id: dev.studio.x.owner.json is itself a valid id, so installing it first makes a later dev.studio.x install fail and leaves a temp file. Keep the records under their own folder, e.g. owners/<id>.json, the way App Hub reserves host file names.

Open versus uninstall (N2)

• uninstall's "is an instance open?" check is not atomic with open_bundle, which does not take INSTALL_LOCK; a concurrent open can run on a deleted jail. Take the lock in open_bundle, or re-check under it.

Context

• App Studio on the phone (ADR 0006 milestone 1): #313 rebased, reviewed, re-validated #477 (supersedes Add developer App Studio with on-device app testing #313): the review thread with the findings above.
• ADR 0006: docs/adr/0006-app-studio-on-the-phone.md.