fix: make recall resilient to transient database contention

[Liyuk]

What

Fixes the graph-memory:recall context that DSH injects into every prompt assembly failing repeatedly — a single transient error turned into a per-round failure.

1. src/store/db.ts — configure PRAGMA busy_timeout

openDb set journal_mode = WAL and foreign_keys = ON but no busy timeout. When two connections to the same database file write concurrently (e.g. a second DSH process sharing ~/.dsh/graph-memory/graph-memory.db), the colliding write fails immediately with SQLITE_BUSY ("database is locked"). With busy_timeout = 5000 the connection waits for the lock so transient contention is retried instead of surfacing as a spurious recall/extraction failure.

2. dsh.ts — evict a failed recall from recallCache

The assembly handler caches { query, value: recaller.recall(query) } per agent. If that Promise rejects, the rejected Promise stays pinned in the cache, and every subsequent system-prompt/assemble re-awaits it — logging [graph-memory] DSH recall failed on every round until the next agent/inbox/claimed clears the entry. The catch block now evicts the entry (guarded by the current query) so the next assembly performs a fresh recall.

Tests

• test/db.test.ts — asserts busy_timeout is configured on every connection, plus a cross-process test: a child process holds a write lock, and this process' write must block and then succeed instead of throwing instantly.
• test/dsh-recall-cache.test.ts — asserts a failed recall is evicted (the next assembly retries, recall invoked twice) while successful recalls stay cached (invoked once across three assemblies).

npm test: 111 tests pass (13 files). npm run build compiles cleanly.

Notes

• Local npm run build requires the optional peer openclaw to be present (it provides openclaw/plugin-sdk types for index.ts); CI's plain npm install installs it.
• While investigating, I found an interesting interaction: @photostructure/sqlite is a synchronous binding, so with two connections in the same process, busy_timeout retries block the event loop (the lock holder can't commit until the retry gives up). That is why the contention test is cross-process — the real multi-host scenario.