CB-622: rename bridge_* tool names to fleet_* in Markdown docs

Rename the eleven MCP tool names (bridge_ack/ask/list/poll/profiles/reply/
send/spawn/status/stop/whoami) to their fleet_* names across the Markdown
documentation. fleet_* is written as the normal name; one deprecation note
in README.md says bridge_* still works for one release.

docs/MCP-Contract.md is renamed only inside section 6 (lines 210-293):
sections 1-5 and 7-11 are stale pre-build design text (CB-609) and are
deliberately left with old names so dead text does not look maintained.

Also renames e2e/bridge_ask_transcript.md to e2e/fleet_ask_transcript.md
to match its content. CLAUDE.md, wiki/, plugin/skills/setup/SKILL.md and
.claude/skills/port-to-opencode/SKILL.md are owned by other units and are
untouched.

.claude/agents/architect.md

@@ -13,7 +13,7 @@ A design task is worked by two architects. Design alone first, then exchange and
 say plainly where you disagree. Do not concede just to agree.
 
 Do only the assigned scope. Note anything outside that scope in one line and do not
-investigate it further. Use `bridge_ask{question}` only when a decision belongs to
+investigate it further. Use `fleet_ask{question}` only when a decision belongs to
 the lead, such as an unclear requirement or two defensible fixes. Do not ask about
 something you can decide by reading more code.
 

.claude/agents/dev.md

@@ -10,7 +10,7 @@ git worktree and branch. Never check out, rebase onto, or push to `main`. Confir
 the worktree root and branch before you edit. Use only paths under that root.
 
 Do only the assigned scope. Note anything outside that scope in one line and do not
-investigate it further. Use `bridge_ask{question}` only when a decision belongs to
+investigate it further. Use `fleet_ask{question}` only when a decision belongs to
 the lead, such as an unclear requirement or two defensible fixes. Do not ask about
 something you can decide by reading more code.
 

.claude/agents/reviewer.md

@@ -12,7 +12,7 @@ Read the whole assigned scope before judging it. Review only that scope. If you
 something outside it, note it in one line and do not investigate it further. Do not
 run the build. The owner makes changes and runs checks.
 
-Use `bridge_ask{question}` only when a decision belongs to the lead, such as an
+Use `fleet_ask{question}` only when a decision belongs to the lead, such as an
 unclear requirement or two defensible fixes. Do not ask about something you can
 decide by reading more code.
 

.claude/skills/implementer/SKILL.md

@@ -5,7 +5,7 @@ description: Implementer-role procedure for a bridged worker — verify your wor
 
 # Implementer worker — procedure
 
-The turn contract (one `bridge_reply`, `bridge_ask` for the lead's decisions, honest reporting,
+The turn contract (one `fleet_reply`, `fleet_ask` for the lead's decisions, honest reporting,
 never merge, never commit `.mcp.json` or `wiki/`) is in **`CLAUDE.md` → Bridge communication →
 Worker** and already applies. This skill is only the *implement-and-hand-off procedure*.
 
@@ -103,7 +103,7 @@ fix it if the cause is yours (e.g. branch not pushed yet), and report the failur
 inventing a URL. If `GITEA_TOKEN` is unset your profile was not granted PR-create: push the branch
 and report its name so the lead opens the PR.
 
-## 6. Hand off — what goes in `bridge_reply`
+## 6. Hand off — what goes in `fleet_reply`
 
 The reply is the entire handoff; the lead cannot see your terminal.
 
@@ -130,7 +130,7 @@ sequenceDiagram
     I->>G: git push -u origin HEAD
     I->>G: POST /pulls (GITEA_TOKEN) — open PR to main
     G-->>I: html_url
-    I->>L: bridge_reply(PR url, branch, files, tests)
+    I->>L: fleet_reply(PR url, branch, files, tests)
     Note over L,G: the lead reviews the PR and merges on green — you never merge
 ```
 

.claude/skills/reviewer/SKILL.md

@@ -5,7 +5,7 @@ description: Reviewer-role procedure for a bridged worker — how to work a revi
 
 # Reviewer worker — procedure
 
-The turn contract (one `bridge_reply`, `bridge_ask` for the lead's decisions, honest reporting,
+The turn contract (one `fleet_reply`, `fleet_ask` for the lead's decisions, honest reporting,
 never merge) is in **`CLAUDE.md` → Bridge communication → Worker** and already applies. This
 skill is only the *review procedure*: how to work the scope, and the exact shape of what you
 send back.
@@ -24,13 +24,13 @@ wrong.
   covers what it was given.
 - Do **not** edit files or run the build. You review; the owner acts.
 
-## 3. Reach for `bridge_ask` only for a genuine fork
+## 3. Reach for `fleet_ask` only for a genuine fork
 
 Ambiguous requirement, a missing acceptance criterion, "intended or a bug?", or two defensible
 fixes with different consequences — those are the lead's call, and guessing produces a
 confident-but-wrong finding. Anything you could settle by reading more code is yours to settle.
 
-## 4. The finding — what goes in `bridge_reply`
+## 4. The finding — what goes in `fleet_reply`
 
 Report the **single most important** real issue in the scope, in these four lines, under
 ~90 words: