Merge branch 'pi/gate-limit' into agents/gitea-mcp

docs/agents/GITEA-SETUP.md

@@ -115,6 +115,26 @@ Neither whitelist is decoration, and neither replaces the other:
 Withholding the review tool from the agents (Phase 5) is defence in depth behind
 these, not a substitute: an agent still has a browser-shaped API token.
 
+### 🔴 What this rule does not gate, said plainly
+
+It binds everyone who reaches Gitea through the API or the web. **It does not
+bind anyone who can run `gitea admin` inside the container** — and that includes
+the supervising agent on the Pi, the one that created the agent accounts and
+minted their tokens. From that shell you can issue an admin token or edit this
+rule, and nothing here would stop you.
+
+That is not a hole to plug here; it is the boundary of what Phase 2 buys, and it
+should be written down rather than discovered. **Phases 1 and 2 gate the two
+containerised agents** — the ones that run unattended on a loop, whose whole
+design assumption is that policy lives somewhere they cannot reach. A supervisor
+with a shell on the host is not in that set, and the protection above should not
+be read as universal.
+
+The distinction is exactly the one Phase 1.2 draws with **Write, not Admin**: the
+looping agents get a permission level that cannot edit the rule that binds them.
+`tools/gitea-protect --verify` asserts that level on every run, which is the
+check that keeps this true rather than merely stated.
+
 > ### Check — and actually run it, do not assume it
 >
 > The whole point of putting this in protection rather than in a document is