fix(dashboard): startup schema reconcile no longer opens state.db as a second writable owner (#107688, salvage #107691 + #107701)

[kshitijk4poor]

The dashboard's startup schema reconcile of this process's own state.db now opens read-only, so a store the gateway already owns never gets a second writable SessionDB owner.

• hermes_cli/web_server_lifecycle.py::_eager_reconcile_own_session_db routes through _open_session_db_for_profile(None, read_only=True) (the path every dashboard router uses) instead of the writable registry acquire(); the read path still bootstraps a missing store or heals a stale schema through ONE writable open when its read probe fails.
• Handle is released with release_or_close; one test asserts the read-only open and the close.

Validation: tests/hermes_cli/test_web_server.py 188 passed; the new test goes red with main's web_server_lifecycle.py.

Root cause: an unconditional writable acquire() ran the full schema init plus a close-time WAL checkpoint beside the gateway's writer on every dashboard start.

Credit: fix cherry-picked from #107691 by @kokhlo (first submitter); regression test from #107701 by @Rroven (Co-authored). Both authorships preserved in git history. Refs #107688 (reviewer note: the FTS-corruption mechanism claimed in the original PR is already fenced by rebuild admission; this lands as hardening, so Refs not Closes).

Closes #107691, closes #107701.

[ehz0ah]

Approval conclusion (formal approval unavailable without explicit repository access)

Reviewed exact head 1caab41045b92dfe2b441a08aec157996cd742e3 against base 4f137c73fcd689e5eb3187e47b223ad293f5f419.

Motivation

The dashboard startup reconciliation opened its own state.db through the writable registry path. On a healthy store that made the dashboard a second writable owner beside the gateway and allowed close-time checkpoint work that a read-only dashboard does not need.

Approach

This change routes startup through the existing profile-aware session opener with read_only=True, then releases or closes the returned handle through the shared lifecycle helper. It reuses the existing guarded bootstrap and schema-heal behavior instead of creating a second repair path.

Concrete changes

_eager_reconcile_own_session_db() now calls _open_session_db_for_profile(None, read_only=True). Healthy stores remain read-only. Missing, zero-byte, and stale stores can still perform the existing single writable bootstrap or reconciliation before reopening read-only. release_or_close() closes the standalone read-only handle without decrementing any registry-owned writer at the same path. The regression test verifies both the access mode and deterministic final close. The contributor mapping is limited to the test co-author carried into this combined PR.

Main-branch risk

I found no blocking regression. Generic corruption is still not escalated into a writable heal. Open and repair failures remain contained by the startup wrapper, and the existing polling path retains responsibility for later retries. Independent review also found no introduced double-close or leaked-handle path. The main residual risk is platform-specific SQLite behavior outside the focused test matrix.

Overall assessment

Approval conclusion. This is the smallest coherent combination of the prior proposals: it removes the unnecessary healthy-store writer, preserves guarded repair behavior, closes the returned handle, and adds the missing regression coverage.

Validation performed:

• Relevant session and schema suites: 222 passed, 1 skipped
• Regression applied to the base: failed as expected because the base still used the writable registry path
• Ruff on changed Python files: passed
• git diff --check: passed
• Hosted Docker amd64, Docker arm64, and Nix checks: passed

English verdict: APPROVE at exact head 1caab41045b92dfe2b441a08aec157996cd742e3. No blocking finding was identified.

[Rroven]

Thanks for folding #107701 into this salvage — the combined approach is genuinely better than what I originally submitted. Two quick notes, from the author of the regression test:

1. The reviewer's catch was correct: my original version discarded the returned SessionDB without releasing it, which would leak a tracked connection. Routing through _open_session_db_for_profile(None, read_only=True) and releasing via release_or_close addresses that properly — thank you for tightening it.

2. I've verified the carried-over test test_startup_eager_reconcile_opens_read_only locally against a patched tree: it goes red against the old writable acquire() and green with the read-only routing, so it does bind the fix. The added close() assertion is the right strengthening.

One small thing worth confirming for the record: _open_session_db_for_profile still performs the one-time writable bootstrap/heal when the read probe fails (missing store or stale schema), so the heal path that #80401 depends on is preserved — the read-only open is only for the healthy store. That matches the test coverage.

No further changes from my side — happy to help re-verify if needed.

[teknium1]

Landed on main via #110934 (d4063e6): your _eager_reconcile_own_session_db refactor is cherry-picked with authorship preserved (@kshitijk4poor; original read-only fix by Rroven via #108076, c9b71eb). Thanks both. Closing since the commits are on main.