fix(sqlite): close connection before untracking on failure (#75629)

[JoaoMarcos44]

Summary

_TrackingMixin.close() in hermes_cli/sqlite_safe_read.py removed a
connection's entry from the live-connection registry before calling the
real close(). When the real close failed — e.g. cross-thread use under
SQLite's default check_same_thread=True — the registry entry was already
gone, so has_live_connection() reported False for a file descriptor that
was still open. That let read_header_bytes_preopen() byte-probe a live
database, which on POSIX cancels every advisory lock this process holds on
that file (including a running VACUUM's exclusive lock), reopening the
exact corruption path this module exists to prevent
("database disk image is malformed").

Fixes #75629.

Root cause

# hermes_cli/sqlite_safe_read.py — _TrackingMixin.close(), before
def close(self) -> None:
    with _live_lock:
        path = getattr(self, "_hermes_tracked_path", None)
        if path is not None:
            self._hermes_tracked_path = None
            untrack_connection(path)   # registry entry gone...
        super().close()                # ...even if this raises

Fix

Close first, untrack only on success — a failed close() now fails
closed, leaving the registry (and therefore the byte-probe guard) honest:

# hermes_cli/sqlite_safe_read.py — _TrackingMixin.close(), after
def close(self) -> None:
    with _live_lock:
        path = getattr(self, "_hermes_tracked_path", None)
        super().close()                # attempt the real close first
        if path is not None:
            self._hermes_tracked_path = None
            untrack_connection(path)   # only on success

Behavior on a successful close is unchanged. On a failed close, the
exception still propagates to the caller exactly as before — the only
change is that the registry entry survives, so has_live_connection() and
read_header_bytes_preopen() keep telling the truth.

Regression test

tests/test_sqlite_lock_safe_inspection.py::test_close_failure_keeps_connection_tracked:

1. A connection is opened via connect_tracked() on a worker thread that
   then blocks (stays alive).
2. The main thread calls close() on it — SQLite raises
   ProgrammingError (cross-thread, default check_same_thread=True).
3. Assert has_live_connection() is still True and
   read_header_bytes_preopen() still returns None (refused).
4. The owning worker thread closes it for real — assert both release.

The same assertion fails on main before this change: step 3 sees
has_live_connection() == False while the descriptor is still open.

Test plan

• pytest tests/test_sqlite_lock_safe_inspection.py — 7/7 passed
  (6 pre-existing + 1 new regression test)
• tests/hermes_cli/test_session_recovery.py,
  tests/hermes_cli/test_kanban_db.py — no new failures. Two failures
  present in test_kanban_db.py
  (test_rate_limit_exit_requeues_without_counting_failure,
  test_worktree_workspace_explicit_target_materializes_linked_worktree)
  are pre-existing on main (confirmed via git stash + rerun before
  this diff), unrelated to sqlite_safe_read.py.

Scope

Only two files touched: hermes_cli/sqlite_safe_read.py (5-line reorder +
one docstring clarification) and the test file above. hermes_state.py is
untouched.

Not fixed here — related, complementary, tracked separately

This PR closes the registry's lie; it does not address why a close can
fail in the first place, or reap connections nobody ever retries closing:

• fix(state): close threaded SessionDB read conns without leaking FDs #74304 — SessionDB's per-thread read connections open with the
  default check_same_thread=True, which is the concrete trigger for the
  failure this PR guards against on that path. That PR opens readers with
  check_same_thread=False instead, so the close succeeds and the guard
  never has to fire there.
• [Bug]: SessionDB retains WAL readers from finished worker threads until shutdown, exhausting RLIMIT_NOFILE #75269 — long-lived processes can accumulate read connections from
  worker threads that finished long ago, none of them reaped until final
  shutdown (RLIMIT_NOFILE pressure, not a registry lie).

All three are independent fixes for independent bugs; this one stands on
its own and should merge regardless of the other two.

Infographic

(Rendered locally and hosted on an isolated, never-merged asset branch —
per .gitignore's PR-infographic policy, the binary never enters this
PR's history or main.)

[alt-glitch]

This was generated by AI during triage.

Duplicate of #75699: both current diffs move SQLite untracking after a successful close and cover the same failed cross-thread-close registry invariant.