docs(02): resolve planning verification artifacts

.planning/phases/02-authentication-foundation/02-RESEARCH.md

@@ -367,22 +367,22 @@ Source: Phase 2 context. [VERIFIED: `.planning/phases/02-authentication-foundati
 |---|-------|---------|---------------|
 | A1 | `com.auth0:jwks-rsa` may need an explicit alias if Ktor's auth JWT dependency does not expose the builder cleanly. | Standard Stack | Minor Gradle dependency task may be missing. |
 
-## Open Questions
+## Open Questions (RESOLVED)
 
-1. **Android secure token storage final choice**
+1. **RESOLVED — Android secure token storage final choice**
    - What we know: no-arg/default multiplatform-settings is not encrypted on Android; AndroidX Security Crypto encrypts preferences but is deprecated. [CITED: https://github.com/russhwolf/multiplatform-settings] [CITED: https://developer.android.com/jetpack/androidx/releases/security]
-   - What's unclear: whether the user accepts deprecated `EncryptedSharedPreferences` for v1 or wants direct Android Keystore-backed storage. [VERIFIED: docs comparison]
-   - Recommendation: planner should add Wave 0 decision task; default to direct platform-specific `SecureAuthStateStore` with an implementation that can be swapped without touching `AuthSession`. [VERIFIED: docs comparison]
+   - Decision from PLAN.md: Phase 2 uses AndroidX Security Crypto `EncryptedSharedPreferences` behind an explicit `SecureAuthStateStore.android.kt` implementation because the project requirement/context explicitly calls out EncryptedSharedPreferences for Android token storage. The deprecation risk is contained behind the `SecureAuthStateStore` seam so a future Android Keystore-backed implementation can replace it without touching `AuthSession`.
+   - Guardrail: auth code must not use no-arg `Settings()` or ordinary `SharedPreferences` for tokens; Plan 03 includes grep-verifiable acceptance criteria for this.
 
-2. **Exposed version and suspend transaction import**
+2. **RESOLVED — Exposed version and suspend transaction import**
    - What we know: current Exposed docs use `suspendTransaction`; project context says `newSuspendedTransaction`. [CITED: https://www.jetbrains.com/help/exposed/transactions.html] [VERIFIED: `.planning/phases/02-authentication-foundation/02-CONTEXT.md`]
-   - What's unclear: which Exposed version will be pinned in `libs.versions.toml`.
-   - Recommendation: pin Exposed first, then write imports from that version's docs/source. [VERIFIED: docs comparison]
+   - Decision from PLAN.md: Plan 02 verifies the exact suspend transaction API/import against the pinned Exposed dependency before implementing DB code. Expected for the current catalog path is `org.jetbrains.exposed.sql.transactions.experimental.newSuspendedTransaction`; if the pinned version requires `suspendTransaction`, execution must use that exact import and record the choice in `02-02-SUMMARY.md`.
+   - Guardrail: no blocking `transaction {}` inside suspend route code.
 
-3. **Ktor patch bump**
+3. **RESOLVED — Ktor patch bump**
    - What we know: repo pins 3.4.1 and current docs/release search show 3.4.3. [VERIFIED: `gradle/libs.versions.toml`] [VERIFIED: Maven search]
-   - What's unclear: whether Phase 2 should include a dependency patch bump.
-   - Recommendation: if bumping, bump the single `ktor` version ref once and run full `./gradlew build`; otherwise add auth artifacts at 3.4.1 for catalog consistency. [VERIFIED: project version catalog]
+   - Decision from PLAN.md: Phase 2 keeps Ktor pinned to the existing catalog version (`3.4.1`) and adds auth artifacts against that same version ref. A patch bump is deferred unless implementation reveals a concrete incompatibility.
+   - Guardrail: do not opportunistically bump Ktor during auth implementation without an explicit failing command or compatibility reason.
 
 ## Environment Availability