`hnsw add failed: attempt to write a readonly database` warning fires every collector tick

[zzallirog]

Symptom

Collector log shows recurring warning, observed once per tick (10Hz / 5Hz / 1Hz depending on --period):

2026-05-24 10:47:59,744 WARNING coolstep.adapters.storage.hnsw: hnsw add failed: attempt to write a readonly database

Sampled on Ryzen 9 7940HS / Arch with HNSW standalone backend enabled (per pyproject.toml chroma-hnswlib>=0.7.6 pin, ADR-022).

Effect

• Log noise — drowns out legitimate warn/info events.
• Likely no functional impact (HNSW writes elsewhere succeed — predictor produces high-confidence predictions, so KNN backbone is operational somewhere).
• Hot path overhead — repeated try/catch + warn formatting per tick adds up.

Hypothesis

Sqlite layer of HNSW persistence (likely data/hnsw/meta.sqlite or similar) is opened readonly somewhere but written to in the add path. Possibly:

• A reader connection survives across tick boundaries with ?mode=ro URI.
• WAL mode mismatch — reader connection blocks writer.
• File permission flip elsewhere.

Where to look

• coolstep/adapters/storage/hnsw.py (suggested by warning prefix)
• Connection lifecycle around add()
• Any sqlite URI with mode=ro / ?immutable=1

Acceptance

Either fix the readonly write attempt OR demote the warning to DEBUG with a one-shot INFO at startup explaining when it appears (e.g. "HNSW persistence disabled because $REASON"). Hot-path warnings every tick should not be informational background noise.