fix: scope database health check to current repo to enable concurrent sessions

[lchachurski]

Summary

Eliminates all cross-repo database locking that prevents concurrent Shotgun sessions on different repositories. The fix touches every code path that previously opened all .kuzu databases in ~/.shotgun-sh/codebases/.

Changes

manager.py — core engine:

• Adds .meta.json sidecar files written alongside each .kuzu database, containing repo_path, name, and indexed_from_cwds. These enable directory-based filtering without acquiring any Kuzu file locks.
• Sidecar lifecycle: created on graph init, updated on CWD access changes, removed on graph/database deletion.
• list_graphs(graph_ids=None) — new optional parameter to open only specified databases instead of globbing all.
• cleanup_corrupted_databases(graph_ids=None) — same scoping pattern.
• detect_database_issues(graph_ids=None) — same scoping pattern (from first commit).
• Consolidated duplicated loop bodies into single candidate-list + iteration pattern.

service.py — service layer:

• list_graphs_for_directory() now reads .meta.json sidecars first to identify candidates, then opens only matching databases. Falls back to full scan when no sidecars exist (backward compat with pre-existing databases).

Agent tools (file_read.py, directory_lister.py, codebase_shell.py):

• Replaced list_graphs() + linear search with direct get_graph(graph_id) when the caller already knows the graph_id.

chat_screen.py:

• Scoped cleanup_corrupted_databases() call to the graph being indexed.
• Scoped detect_database_issues() retry flows to relevant graph_ids.

app.py:

• Scoped startup detect_database_issues() to current repo's graph_id only.

Root Cause

On startup, detect_database_issues() globbed every .kuzu file in ~/.shotgun-sh/codebases/ and attempted to open each one. When another Shotgun instance was already running on a different repository, its database file was exclusively locked by Kuzu. The health check reported this as a "locked database" issue, and the TUI showed a blocking dialog — even though the current repo's database was perfectly accessible.

The same pattern existed in list_graphs(), cleanup_corrupted_databases(), and list_graphs_for_directory() — all opening every database for every operation.

Test Results

Tested with real_ladybug==0.15.1 against 3 simulated repos (atoma, auto-research, voice-feedback-analytics — mirroring the actual layout) using multiprocessing to hold database locks:

T1 OLD blocks with peer locks:      PASS (bug reproduced — 2 locked, TUI would block)
T2 NEW scoped detect:               PASS (only checks own database)
T3 list_graphs scoped:              PASS (opens 1/3, not 3/3)
T4 sidecar filtering 3 repos:       PASS (each CWD sees only its own graph)
T5 unrelated CWD empty:             PASS (no false positives)
T6 scoped cleanup:                  PASS (corrupted DB found, locked peers untouched)
T7 backward compat:                 PASS (full scan works when no sidecars/locks)
T8 uniqueness:                      PASS (3 distinct graph_ids)

Known Limitation

The list_graphs() method (used by codebase_shell when no graph_id is specified) still falls back to a full scan. This is the "show all indexed codebases" use case — rare during normal operation but could be improved with a registry approach in the future.

Test Plan

• Automated 8-test suite with real_ladybug confirming bug reproduction and fix across 3 repos
• Manual test: start Shotgun in 3 different repos simultaneously — all should run concurrently
• Verify single-instance startup is unaffected (backward compat)
• Verify .meta.json files are created during indexing and cleaned up on deletion

Closes #534

[lchachurski]

better solution selected