docs: phase 0 audit, chunk plan, ADRs and pinned Gitea 28.1.0 swagger

Inventory and gap analysis of the 0.2.0 codebase against the full Gitea API
and the official gitea-mcp toolset, the B1..B11 + security chunk plan, ADRs
0001-0006 for the full-access rebuild, SDK/OAuth research notes, and the
instance swagger pinned for tool generation. The audit-logging doc moves to
docs/audit-logging.md.

docs/adr/0001-full-access-by-default.md

@@ -0,0 +1,33 @@
+# ADR 0001: full access by default
+
+Status: accepted (2026-10-14, owner decision)
+
+## Context
+
+Until 0.2.0 the contract in `AGENTS.md` made writes opt-in (`WRITE_MODE=false`),
+denied admin and credential endpoints by default, and emulated per-user rights
+on a shared service PAT. The owner runs this server with a full-scope admin
+token and wants every Gitea capability reachable through MCP: read, write,
+secrets, admin and instance settings.
+
+## Decision
+
+- Every tool generated from the Gitea API is enabled by default, including
+  admin, secrets, deletes and Sudo.
+- The server does not decide what is safe. The owner restricts exposure through
+  configuration (`READ_ONLY`, `TOOLSETS`, `DISABLED_TOOLS`) and through the scope
+  of the Gitea token they configure.
+- Kept invariants: audit event for every tool call, no secrets or tokens in
+  logs/errors/results, no stack traces by default, `127.0.0.1` default bind,
+  fail-closed HTTP auth (a non-loopback bind refuses to start without auth),
+  untrusted-content labelling, schema validation with no extra properties,
+  response size bounds.
+- Removed invariants: write opt-in, admin default-deny, the `gitea_request`
+  denylist and known-path gate, the resource-type authorization gate.
+
+## Consequences
+
+A leaked MCP bearer token is equivalent to the configured Gitea token. That is
+why HTTP auth is mandatory off-loopback and the token comparison is constant
+time (see `docs/security.md`). The old `AGENTS.md` invariants are rewritten in
+the same changeset.