Add repo-publication-auditor to Quality & Security

[ArcticFox2029]

One subagent for a gap in 04. Quality & Security: the category has security-auditor for vulnerabilities and compliance-auditor for frameworks, but nothing for the one-time, irreversible act of making a repository public.

Those are different audits. A vulnerability review asks what an attacker could do to running code; this asks what a stranger can read the day the repo goes public — and what a scanner, a search engine, or a colleague's employer will notice. The second kind cannot be fixed afterwards: a force-push rewrites history on the server, but it does not un-fetch what a mirror bot cloned in the first ten minutes, and it does not recall a key a partner scanner already forwarded to a vendor.

Every check came from a real mistake, not a checklist

• The history is the artifact, not the working tree. Auditing git status misses a secret removed in a later commit, and .gitignore added after the fact never untracks anything. A fully-ignored data/ directory does not appear in git status at all, so it has to be opened rather than assumed clean.
• GitHub attributes a commit by the email in the commit object, not by who pushed it. A repository can publish an employer on every line of its contribution graph. The agent is told to report the count, because 665 of 673 commits is a different decision from 2 of 673.
• Push protection treats an invented credential exactly like a real one. Partner scanning forwards an AKIA… string to AWS within minutes, and the vendor then tries to revoke a key that never existed. So the agent does not tell an owner to delete their redaction-test fixture — it recommends placeholders plus a seeded local generator, which keeps the fixture complete on disk and absent from the published tree.
• A README number measured in the author's working copy may be measuring something else. Tools that resolve a project root by walking up the directory tree find the outer repository when the project sits inside one, so a benchmark run in place can silently report the wrong thing. The agent re-runs the README's own commands in a fresh clone and compares.

Verification

Every shell command in the agent was executed before being written down, against real repositories, and each found real instances — the author-email sweep, the credential-shape sweep (verified against a corpus with known planted credentials: 16 found planted, 0 after templating), the machine-path sweep, and the history enumeration.

Files updated, per CONTRIBUTING

• categories/04-quality-security/repo-publication-auditor.md — the agent
• README.md — entry in the category section, alphabetical (after qa-expert, before security-auditor)
• categories/04-quality-security/README.md — description, and a Quick Selection Guide row in the same position
• categories/04-quality-security/.claude-plugin/plugin.json — agent registered, 1.1.1 → 1.2.0
• .claude-plugin/marketplace.json — voltagent-qa-sec synced to 1.2.0

The marketplace bump is a textual edit rather than a re-serialise, so the diff is the one line that changed — the file keeps keywords arrays on a single line and json.dumps cannot reproduce that.

tools: Read, Grep, Glob, Bash, model: inherit. Bash is needed because the git history checks are the substance of it; everything it runs is read-only.