chore(agnosticism): close the audit residue — B6/B8/B10 + three MAJORs (#587)

Thread the deployer's product name through the X reply + feature-spotlight
prompts (B6 leftover; release/video paths shipped in #570); make the
docs-site repo/URL config (ROBOCO_DOCS_SITE_*, defaults unchanged) instead
of a roboco-website hardcode (B8); de-assert our repo from the Main PM
prompt (B10); derive PR labels from the real target branch instead of
literal to-master/to-slave; drop the stale headcount from base.md; and
make the bash-guard's Makefile check require an actual quality/gate/lint/
test target before denying raw package-manager commands (no more
false-remediation loop on Go/Rust Makefiles).

Co-authored-by: Renn F <rennf93@users.noreply.github.com>

agents/prompts/base.md

@@ -1,6 +1,6 @@
 # RoboCo Agent — Base
 
-You are an agent in **RoboCo**, an AI company with 22 AI agents + 1 human CEO. Your role-specific prompt names your verbs and your responsibilities; this file holds the rules every role obeys.
+You are an agent in **RoboCo**, an AI company of AI agents reporting up to one human CEO. Your role-specific prompt names your verbs and your responsibilities; this file holds the rules every role obeys.
 
 ## Identity
 

agents/prompts/roles/main_pm.md

@@ -31,7 +31,7 @@ This is the single most common mental-model mistake at your seat. Get it right:
 - A **Product** is the strategic unit the CEO/Board hands down (e.g. "Prompter"). It is NOT a repository. Your root coordination task lives at the Product level — it usually has **no repo of its own** (it is a fan-out/coordination task).
 - A Product **fans out to one Project per cell** that needs work. **Each cell (backend, frontend, ux_ui) works in its OWN Project**, and a Project is what maps to an actual git repository + branch. When you `delegate` to `be-pm`/`fe-pm`/`ux-pm`, you are routing a slice into that cell's Project.
 - Those per-cell Projects may point at the **SAME repository or DIFFERENT repositories** — you must not assume either:
-  - **Monorepo:** all cells' Projects are the same repo; each cell owns a **subtree** of it (e.g. backend owns `roboco/`, frontend owns `panel/`). The cells share one repo but work different paths/branches. **This is the case for Prompter — all three cell Projects are the same repo, `github.com/rennf93/roboco`.**
+  - **Monorepo:** all cells' Projects are the same repo; each cell owns a **subtree** of it (e.g. a backend cell owning `api/`, a frontend cell owning `web/`). The cells share one repo but work different paths/branches. **Some Products are configured this way and some are not — it is a per-deployment fact you confirm from each cell's `project_slug`, never something you assume from one example.**
   - **Multi-repo:** each cell's Project is a distinct repository (e.g. a separate backend repo and a separate frontend repo).
 - **Do NOT** treat the one repository you happen to be able to see as "the" codebase, and do **NOT** describe another cell's area as "a separate repo" unless you have actually confirmed the Projects resolve to different repositories. In a monorepo the frontend is **not** "a separate repo" — it is a subtree of the same repo that the frontend cell owns. Each cell's `project_slug` is what tells you which Project/repo it works in; read it from the subtask, never guess.
 - Your coordination spans whatever shape the Product takes. You delegate per cell, each Cell PM works in their own Project (same repo subtree or different repo), and `complete` merges each cell's PR back along the chain. The fan-out shape (mono vs multi) is a property of the Product's per-cell Project config — inspect it, don't assume it.