Merge #531: separate the blocked forge MCP server from the working GITEA_TOKEN

Charter wording only — 9 insertions, 4 deletions, one file. CI run 1780 on
be07ed2: success.

Resolves the "charter may be stale" item I had been carrying. It was not stale.
Two workers reporting working forge access and the charter saying forge tools
hold a blocked credential were both correct, about two different credentials:
the repo-scoped GITEA_TOKEN the daemon injects (which opens every worker PR,
per implementer SKILL.md step 5) versus the forge MCP server that leaks in from
the operator's user-scope config (which is deliberately blocked). The wording
did not separate them, and a worker could have read it as "I cannot reach the
forge" and skipped opening its PR.

Both sentences now name the MCP server specifically and state that the injected
token is a separate, working route.

Canonical block and wiki template verified byte-identical after the edit — the
CLAUDE.md sync script reports "in sync: True". The wiki commit is d02a55d on
wiki's own main, pushed and verified by ref (ls-remote matched local HEAD), not
by exit code. The submodule pointer stayed unstaged.

Not re-measured in this change: that the blocked MCP credential does fail every
call. That claim is the existing charter's and I only narrowed what it refers
to. It would need its own probe with a request that cannot succeed on its
merits, so that a rejection can only mean the block.

CLAUDE.md

@@ -96,8 +96,10 @@ below are the procedure — run them in order, every task, not only the big ones
    that answers it. **A worker's ask waits ~55 seconds, and no nudge makes that longer** — so never
    brief a worker to "ask me". Decide before you delegate, or give it an explicit default.
 6. **Verify yourself.** Re-run the build and the checks. A worker cannot run your IDE tooling, any
-   forge tools it appears to have hold a blocked credential and fail, and a piped command
-   (`… | tail`) hides failures behind a zero exit — never promote a worker's "clean" to a fact.
+   forge MCP server it appears to have holds a blocked credential and fails every call, and a piped
+   command (`… | tail`) hides failures behind a zero exit — never promote a worker's "clean" to a
+   fact. Its injected repo-scoped `GITEA_TOKEN` is a different credential and does work, so a worker
+   reporting that it opened its own PR is reporting something it really can do.
 7. **Review — fan out.** Spawn reviewers against the diff, one per dimension or per file, with
    `wait:false`. Never the implementer of the scope it reviews, and brief them from the diff — not
    from the implementer's rationale, which carries its own blind spot. Dispatch each PR's reviewers
@@ -200,8 +202,11 @@ simply complies has thrown away the reason there are two of you.
    assume them.** What you mount depends on your backend: an opencode member gets the bridge and
    nothing else, while a Claude Code member also inherits the operator's user-scope MCP servers,
    which the bridge never chose for you. Two rules follow. The primary's IDE tooling is still not
-   yours, whatever you see. And **a mounted tool is not a working tool** — the forge server you may
-   find there holds a deliberately blocked credential and fails every call, by design.
+   yours, whatever you see. And **a mounted tool is not a working tool** — the forge MCP server you
+   may find there holds a deliberately blocked credential and fails every call, by design. That is
+   not your only forge route, and the two must not be confused: the repo-scoped `GITEA_TOKEN` the
+   daemon injects into your environment does work, and using it to open your own PR is part of the
+   job. A blocked MCP tool is never a reason to skip that step.
 6. **Never merge.** Stage files explicitly — never `git add -A` — and leave alone anything the
    project marks as not-yours-to-commit.