#2941 Namespace advice in the slow-lock warning is wrong for a single repo on a local datastore

Summary

When a per-model lock wait takes more than 5 s and the datastore has no namespace, swamp suggests setting a namespace. In a single repo on its local filesystem datastore that advice is wrong: no other repo shares the lock, so a namespace changes nothing. The wait comes from contention inside one process, such as a wide forEach against one model instance.

Observed

swamp 20261002.023954.0, Linux, local filesystem datastore, one repo, no namespace. A workflow runs a 13-wide forEach of command/shell (sleep 0.2) against one model instance. Every waiter that took 5 s or more logged:

[WRN] datastore·lock: Lock acquisition took 5498ms — if multiple repos share this datastore without namespaces, all writes serialize behind a single lock. Run 'swamp datastore namespace set <name>' to scope each repo to its own lock and index

The holder named in the matching Waiting for lock line was the same host and the same pid as the waiter.

Cause

registerDatastoreSyncNamed in src/infrastructure/persistence/datastore_sync_coordinator.ts (around line 314) prints the warning whenever lockMs > 5_000 && !namespace. It does not check whether the datastore can be shared, or whether the holder is another process or repo. The same text appears in src/cli/repo_context.ts around lines 1851 and 1970.

Expected

Suggest a namespace only when it could help: a shared or custom datastore, or a holder from another repo or host. When the holder is this process, either say nothing or name the real cause, for example that concurrent steps against one model instance serialize on its lock.

Related

Found while reproducing swamp-club#2870, which covers the per-model lock backoff that makes these waits long.