Hardening candidates: v2.28.0

[jeiel85]

Hardening candidates surfaced by the "open notes in preview" lock (#200, PR #201) and the RTL note-direction fix (#146, PR #202). Each item is one line of what/why/blast-radius; none blocks the release.

• Add an automated test for "a just-created note opens in edit when preview-open is on" — what: the FAB creates the note first and opens it with a real id, so the edit-mode guard is content.isNotEmpty() and is device-verified only; why: dropping that guard silently breaks "new notes still open for editing"; impact: extract the open-mode decision into a pure function + unit test, or an EditorScreen load-effect test.
• Broaden coverage of the long-press lock gesture — what: the Initial-pass pointerInput that fires the lock and consumes the release is covered by one Robolectric case + manual device; why: coexisting with IconButton's tap is subtle and could regress across Android versions or with TalkBack; impact: editor top bar; add tap-after-longpress / cancel / a11y cases (and ideally an instrumented gesture test).
• ViewModeLockedTint is a hardcoded amber outside the color scheme — what: the locked-state tint is a fixed Color(0xFFF57C00); why: it is not contrast-checked against Material You / dynamic-color backgrounds or verified in both themes; impact: editor top bar visuals; consider a theme token or a contrast assertion.
• No Roborazzi golden for the locked (amber) view-toggle state — what: only the unlocked top bar is snapshotted; why: the orange indicator could break unnoticed; impact: add a locked-state golden (needs a Linux record run).
• settings.first() on the note-load path has no timeout/fallback — what: the editor suspends on the first DataStore emission before showing an existing note; why: a stalled DataStore would hang note-open with no fallback; impact: editor load effect; low likelihood, but a bounded read or default-on-timeout is safer.
• No RTL regression golden for note content (Doesn't it support right to left languages? #146) — what: the TextDirection.Content fix is device-verified only; why: a future typography refactor could silently drop it; impact: add a Roborazzi golden with an RTL sample (needs a Linux record run).
• RTL editing edge cases unverified (Doesn't it support right to left languages? #146) — what: cursor placement, selection, and mixed LTR/RTL lines in the editor's BasicTextField were not exercised; why: content-direction fixes alignment but bidi editing can still surprise; impact: a broader RTL QA pass.
• App UI strings still fall back to English in RTL system locales — what: with the layout now mirroring and content laid out RTL, menu/label strings remain English (no ar/he/fa translations); why: a known gap called out in Doesn't it support right to left languages? #146; impact: a separate i18n effort, not layout — noted here so it is tracked.

[jeiel85]

Audited against the tree at 9969025 (v2.31.0) as part of a sweep over every open hardening tracker. All eight items still stand — nothing here has been picked up since the issue was filed, so this is a re-confirmation rather than a status change.

Spot checks that would have shown otherwise:

• Open-mode decision — still inline in the editor load effect; no unit test names it.
• Long-press lock gesture — EditorTopAppBarLockTest still holds exactly one @Test.
• ViewModeLockedTint — still Color(0xFFF57C00) at EditorTopAppBar.kt:41, outside the scheme.
• Locked-state golden — absent; the Roborazzi set has editor_top_appbar_phone and friends, no locked variant.
• settings.first() — still unbounded at EditorScreen.kt:319.
• RTL content golden — absent. TextDirection.Content is applied in Theme.kt and covered by nothing.
• RTL editing edges — unchanged.
• values-ar / values-he / values-fa — none exist, so the English fallback in RTL locales is intact.

This is the oldest open tracker in the backlog and the only one with a 0/8 rate.