finitechat: single-writer store lease + read-only one-shots + deterministic home-topic key

[futurepaul]

What

Makes the cross-process poison-entry incident class impossible instead of timing-dependent:

1. Single-writer lease (finitechat-client): SqliteClientStore::open now takes an advisory exclusive lock on <db>.writer-lease (fs4 flock/LockFileEx). A second process opening the same store for write fails fast with ClientStoreError::WriterLeaseHeld instead of silently sharing MLS ratchet state. In-process handles share the lease through a Weak registry (flock is per open-file-description). New open_read_only for diagnostics: no lease, no migrations, every write rejected with ClientStoreError::ReadOnly.
2. One-shot CLI reads are genuinely read-only (finitechat-cli): hermes room-status no longer opens a runtime at all (it dispatched a full StartRuntime write tick against the store the resident bridge owns); it reads the store via open_read_only and computes the same summary. Plain app state (no --start-runtime) opens a read-only runtime; read-only dispatch fails with FiniteChatCoreError::ReadOnly.
3. Deterministic home-topic idempotency (finitechat-core): ensure_home_topic uses home-topic:<room>:<account>:<device> (per-device because late-joining/linking devices cannot decrypt pre-membership entries and must publish their own create). On the server's typed 409 idempotency_conflict the runtime adopts the deterministic metadata into the local projection without appending — a second entry that members might never process is never written. Provisional device-link rooms no longer re-fire ensure_home_topic on every sync tick.

Why

The durable smoke failed 6/6 on slow-I/O CI runners: one-shot docker exec finitechat hermes room-status / app state execs raced the resident bridge on the same store; diverged in-memory MLS ratchets emitted ciphertexts for the same generation, and the second entry permanently wedges every other member (mls_application_ciphertext, the 2026-08-06 poison-entry class). Chat correctness must not depend on I/O timing.

Server idempotency was verified first: same key + byte-identical request replays the original receipt; same key + any different payload → typed 409. Exact replay of a re-sent MLS ciphertext is impossible (fresh randomness per create_message), which is why conflict handling is local adoption, and why a fresh-key retry was rejected (it would append the very ciphertext that conflicted).

repair skip-entry intentionally keeps the writer open (it repairs the real store with the service stopped) and now enforcedly holds the lease — it fails fast if the service is still running. diagnose rejected-entry (byte copies) and capture room-log (no store) are unaffected.

Tests

• client: writer_lease_fails_fast_for_a_second_process (real cross-process re-exec), read_only_open_reads_alongside_the_writer_and_rejects_writes
• core: read_only_runtime_reports_persisted_state_and_rejects_dispatch, diverged_double_fired_home_topic_adopts_instead_of_poisoning_the_log
• cli: room_status_and_app_state_read_read_only_while_a_writer_holds_the_store (hermes_flow integration)

cargo fmt --check, clippy --all-targets -D warnings on all four touched crates, and cargo test for client/core/cli/daemon all green; cargo check for hosted-device and rmp green; Swift bindings unaffected (gitignored, CI-regenerated; regen command verified locally).

Not changed: other send paths keep random keys (only home-topic is check-then-send); the lease is advisory and same-machine by design; the durable docker smoke was not re-run (its concurrent one-shots are now read-only by construction and covered by the new integration test).