docs: record the concurrent-agent trap that RD-17 hit

`/clear` ends the supervisor's context. It does not stop the developer agent
that session spawned. A fresh supervisor read the half-finished tree as an
interrupted session and dispatched a second agent onto the same ticket. Both
agents then ran `dotnet test` in one checkout, which truncated the shared
SQLite file and produced the stale-database failure the Troubleshooting
section already records under a different cause.

Also record that a bare `dotnet test` runs the OpenZaak integration test that
both CI scripts filter out.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/project/readable-codebase/README.md

@@ -235,3 +235,31 @@ rm -f backend/bigregister.db backend/src/BigRegister.Api/bigregister.db \
 ```
 
 These are build artifacts, not fixtures — removing them is always safe.
+
+A second cause reaches the same error: **two agents running `dotnet test` at the same time in
+one checkout.** They share those files, so one run truncates the other's database. RD-17 hit
+this. The fix is the same three deletions, but the cause is concurrency — see the next entry.
+
+**`dotnet test` reports one failure in `OpenZaakIntegrationTests`.** That test carries
+`[Trait("Category", "Integration")]` and needs the live OpenZaak harness. Both `ci.yml` and
+`scripts/ci-local.sh` filter it out. A bare `dotnet test` does not. Run `npm run ci` — a bare
+`dotnet test` is the wrong command, not a red build.
+
+**An unexplained dirty tree may be a running agent, not an interrupted session.** `/clear`
+ends the supervisor's context. It does **not** stop the `developer` agent that session
+spawned. That agent keeps writing to the same branch. In RD-17 a fresh supervisor read the
+half-finished tree as an interrupted session, wrote a "continue from here" ticket, and
+dispatched a second agent onto the work the first was still doing. Both agents then ran the
+backend tests together, which produced the stale-database failure above.
+
+Nothing was lost, because the second agent committed first and the first agent checked before
+committing rather than committing blindly. That was luck. Before you dispatch, confirm no
+agent is live:
+
+```bash
+git status --short          # modified files nobody in THIS session touched = suspect
+git log --oneline -1        # did an agent already commit the ticket?
+```
+
+If the tree is dirty and this session did not dirty it, find the agent before you write a
+ticket around the evidence it leaves.