v1.108.280 — A cache keyed on a spelling is keyed on the caller's working directory

A cache keyed on a spelling is keyed on the caller's working directory

Reported and fixed by @rknighton in #473, closing #465.

_ensure_perf_db_locked documents its connection cache as "keyed by resolved path". _perf_db_path returned the path unresolved, so the key was whatever spelling the caller happened to pass. Both exits now resolve.

A relative storage_path made the key depend on the process CWD. After a chdir the same key names a different database: the liveness probe consults the new location while the cached connection still points at the old file, and a row recorded for one store is written into another's. That is the failure v1.108.188 fixed for the writers, reappearing one layer down in the cache key.

The alias case is smaller and still real. _perf_conns has no cap and no eviction, so every spelling of one directory held its own connection for the life of the process.

Fixed at the helper rather than at the cache: _perf_db_path has one caller and all three telemetry sinks reach the cache through it, so every consumer inherits the fix, including _persist_session_yield_locked, whose reachability the issue left open.

Existing installs are unaffected. The default store is absolute with no symlinks, where resolve() returns it unchanged. Nothing backfills or migrates rows that already landed in the wrong file.

Three regression tests. Reverting either .resolve() on its own turns them red — the row-level tests all pass an explicit base_path, so the no-argument exit carries its own assertion rather than inheriting coverage.

Local suite 7822 passed / 9 skipped / 0 failed; 3.13 CI-env reproduce 7816 / 15, the same 7831 total. ruff check src/ clean. All 9 CI jobs green on d6cea51.