feat: a desktop entry point, and the first code here that runs

Phase 5. `press.mantra.desktop.MainKt` has been named by the
compose.desktop block since before this work started and did not exist;
now it does, and `./gradlew :composeApp:run` opens a window.

**The window opens onto a passphrase gate, not onto the app.** That is
phase 3 landing here rather than there, and it was not in the plan.
keyStoreEncryption(keyName, plainText) takes no secret, because on android
the OS keystore serves keys without asking anybody anything -- so a
passphrase scheme needs an unlock the expect signature cannot express.
MainKt calls JvmKeyStore.unlock before MantraApp is composed, off the ui
thread, because Argon2id at 64 MiB is deliberately slow enough to stop the
window painting. The gate says on its face that this build is not for real
funds.

One application directory is handed to both the mantra and the phoenix
context, so a single install keeps a single place on disk rather than two
named after different projects.

**MantraDatabaseJvmTest is the part worth keeping.** Running the app
proves the window paints; it proves nothing about Room, because the gate
stops before anything touches the database. Six tests now open it: the
schema is created, a profile survives a write and a read, upsert replaces
rather than duplicates, the @Transaction relation query behind
findChatRoomById reads back, a soft-deleted room stops being found, and
the on-disk builder writes under the context directory rather than
java.io.tmpdir. This is the first time this database has been opened
anywhere but android, and it covers exactly what the compiler cannot see
-- that Room's ksp output for this target is usable, that the *host*
SQLite native loads where the android artifact's would not, and that the
58 queries forced from blocking to suspend still return what they stored.

Both of that test's first drafts were wrong in ways worth keeping the
scars of. Every write failed with SQLite error 787 because Profile has a
foreign key onto NostrEvent and the test never created the parent row --
which is evidence rather than an annoyance, since a schema whose
constraints were quietly off would have let all of it pass. And Kind is a
typealias for Int, not a constructor.

Window sizing is 480x900: a starting size that does not immediately
misrepresent layouts only ever exercised at phone widths, not a considered
desktop layout. That, along with back handling and any ui offering an nfc
affordance, is the shakeout this phase names and does not do.

Verified, all five green: :composeApp:compileKotlinJvm,
:composeApp:compileDebugKotlinAndroid, :composeApp:testDebugUnitTest (52),
:composeApp:jvmTest (6), and the fork's :library:jvmTest (97).

Not verified: nothing past the gate. No seed has been written, no business
started, no relay contacted. A gradle `run` killed with SIGTERM reports
BUILD FAILED with exit value 143 -- that is the signal, not the app.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/jvm-target.md

@@ -538,7 +538,21 @@ expect anyway:
   change; noted because it is not available on all KMP targets and is easy to
   trip over later.
 
-**Verification:** `./gradlew :composeApp:run`.
+`main` also has to **unlock the key store before anything else runs**, which is the
+consequence of Phase 3 that lands here. Android and ios have no screen like this
+because their OS keystores serve keys without asking; on the jvm the passphrase *is*
+the protection, so the window opens onto a gate rather than onto the app.
+
+**Verification:** `./gradlew :composeApp:run`, and then a jvm test that opens the
+database. The run proves the window paints; it does not prove Room works, because the
+gate stops before anything touches the database. `MantraDatabaseJvmTest` covers what
+the compiler cannot see — that Room's KSP output for this target is usable, that the
+**host** SQLite native loads (the android artifact ships only android-ABI `.so` files
+and would fail here), that the schema is created, and that the queries forced from
+blocking to `suspend` still read back what they wrote.
+
+Note that a gradle `run` killed with SIGTERM reports `BUILD FAILED` with exit value
+143. That is the signal, not the app.
 
 ---
 
@@ -553,6 +567,13 @@ expect anyway:
 | 4 | mantra actuals (16) | 1–2 | 1, 2, 3 |
 | 5 | desktop entry point + shakeout | 1–2 | 4 |
 
+Phases 0–5 are now implemented. What each phase actually turned out to require, as
+opposed to what was predicted here, is recorded in the git history on
+`claude/jvm-target-actuals` (the fork) and this branch. The two largest surprises were
+not in any phase's description: Room refuses to generate a DAO with blocking methods
+for a non-android target (Phase 4), and a passphrase-derived key store needs an unlock
+step the `expect` signature cannot express, which lands in Phase 5 rather than 3.
+
 **Roughly one focused week to a launchable desktop build**, assuming Phase 3
 takes the passphrase-derived KEK and the build is marked dev-only. Real desktop
 key storage is separate work that should not be folded into this estimate, and