Refuse to start with the state store or .env inside the clone

Answering "is the workspace where the agent runs, or what it works
on?" — it is what it works on, and conflating the two is dangerous
rather than merely untidy.

The agent commits its workspace with git add -A and pushes it, so
anything inside the clone reaches the project repository. A .env
placed there would publish the LiteLLM, Matrix and Gitea tokens as a
side effect of the agent working correctly: silently, once, and
probably unnoticed. Startup now refuses both that and a state store
inside the clone, and .env.example documents the intended layout.

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

.env.example

@@ -37,6 +37,19 @@ NISSE_GITEA_OPERATORS=your-gitea-login
 
 # --- Running the agent (the demo, not the tests) ---
 # The tests use NISSE_GITEA_TEST_REPO; a running agent uses these.
+#
+# Layout. NISSE_WORKSPACE is the *clone the agent works in*, not the directory
+# the agent runs from — they must not be the same place:
+#
+#   ~/nisse-demo-workspace/     deployment root, not a git repo
+#   ├── .env                    this file
+#   ├── state.db                the A2 state store
+#   └── project/                NISSE_WORKSPACE, the clone
+#
+# The agent commits its workspace with `git add -A` and pushes it, so anything
+# inside the clone reaches the project repository. A .env or state store placed
+# there would publish credentials as a side effect of the agent working
+# correctly; startup refuses to proceed if either is inside the workspace.
 NISSE_STATE_DB=~/nisse-demo-workspace/state.db
 NISSE_WORKSPACE=~/nisse-demo-workspace/project
 NISSE_PROJECT=demo