Keep the app answering when a command holds the core, and save ink on text

[XrxcGH]

Fixes beta 4's T2-1 (ink on text never saved) and contains T2-3 (the core stopped responding and Close did nothing).

T2-1: ink on text never saves

Every geometry reader (file reads, edits, frames, notebook styles) now rounds the way the writer does (0.01; crops 6 decimals; line height 2), so the save's read-back check passes. A failed save forgets its orphan .onk segment, and the title bar shows "Couldn't save" from core:save-failed instead of "Saved".

T2-3: the core stops responding, Close does nothing

What the T2 profile and log show: the core answered until 14:48:54, then nothing at all was logged, not even the exit handshake's warning that a Close must produce within 3 s. So the webview's IPC was dead, not only the core: every core command took the core's one lock unbounded on an async worker, so once one command never returned, each later one parked a worker and an IPC request until the channel was full. (Tauri 2.12 sends Windows invokes as fetch() on the ipc custom protocol, so Chromium's per-host connection cap plausibly applies; not measured.)

The command that held the core at 14:49 is not identified. Every lock order in the core was checked by hand and is consistent; the only unbounded cross-thread waits under the core lock were the journal opens, which the inline rename and the new page's first edit both go through. This PR is containment plus diagnosis, so the next occurrence names its holder:

1. Journal opens give up after OPEN_TIMEOUT (10 s) and the page runs without a journal (spec 20.12); the worker detaches a journal nobody waits for.
2. Every core command runs on a blocking thread (CoreBridge::run), so a wait never parks the async runtime.
3. A command waits at most COMMAND_WAIT (15 s, longer than OPEN_TIMEOUT so a stuck open gives up before the commands behind it) at a Condvar door and then fails with code coreBusy, naming the holder. The failed request completes, so the IPC channel stays open for Close, the log and everything else.
4. The exit waits up to the flush time and then exits without the final save; the journals keep the edits.
5. A watchdog names the command holding the core after 10 s (core:stalled/core:responsive); the title bar shows "Not responding", also as soon as any command fails as coreBusy.
6. Interface: a coreBusy page_apply is a non-resync error: the text stays unsent with its riders, the "not kept" toast shows, and the next flush sends it.

Known limits

• Root cause of the 14:49 hold: unidentified (see above). The watchdog and the coreBusy message exist to catch it next time.
• IPC saturation: there is no frontend cap on pending invokes, so with many pages open (one page_apply in flight each, plus tree and search calls) more than ~6 concurrent core commands can still fill the channel for up to 15 s per round while the core is held. Acceptable for beta.
• Rust callers outside bridge.run (external.rs notebook_roots, backup.rs) now get a coreBusy error after 15 s instead of blocking forever; both handle it.

Verification

• cargo test -p opennote --lib core_bridge; cargo test -p opennote-core journal_thread; cargo clippy -p opennote -p opennote-core --all-targets.
• vitest: textSync, tauri, saveHealth (30 passed), SaveStatus component test (2 passed); app:typecheck, eslint, prettier clean.
• Branch merged with origin/beta before the final run.

🤖 Generated with Claude Code

[XrxcGH]

Merged through beta in the Beta 5 integration (beta head 9e2ba25); GitHub marked this PR merged when beta was pushed.