docs(gitea): add .env.example template for the gitea MCP server env vars

The README documented exporting GITEA_ACCESS_TOKEN and GITEA_HOST directly
but gave no discoverable template, and the repo has an established
per-plugin example-file convention (plugins/git/config.example.json) this
skipped. Adds plugins/gitea/.env.example with placeholder values and points
the README at it instead of duplicating the instructions inline.

Verified plugins/gitea/.env.example is trackable, not swallowed by
.gitignore's .env.* exclusion: the !.env.example allowlist line is
unanchored and matches at any depth. Also verified apm has no dotenv
auto-load anywhere in its source, so the file's instructions say to source
it explicitly rather than implying it's picked up automatically.

Full pre-push gate green, all 16 hooks. Test suite green, 26 suites.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EmiHiknxqtZPEBnW7ujgNz

plugins/gitea/.env.example

@@ -0,0 +1,20 @@
+# Environment variables required by the gitea MCP server declared in
+# plugins/gitea/.mcp.json. apm passes these ${VAR} references through to the
+# deployed MCP config unexpanded; Claude Code resolves them from the process
+# environment at server startup. Neither value is ever committed to this repo.
+#
+# Nothing in this repo auto-loads a .env file -- apm has no dotenv support.
+# Copy this file to .env at the repo root, fill in real values, then export it
+# into your shell before starting Claude Code, e.g.:
+#
+#   set -a; source .env; set +a
+#
+# Or skip the file and export the two variables directly in your shell
+# profile. Either way, never commit .env -- .gitignore already excludes it.
+
+# A Gitea access token, scoped to the repositories this agent should reach.
+# Generate one in Gitea under Settings > Applications.
+GITEA_ACCESS_TOKEN=<your-gitea-access-token>
+
+# The base URL of your Gitea instance, including scheme.
+GITEA_HOST=https://<your-gitea-host>