Give the spec workstream leads owner parity

[rocklambros]

What changed

Adds @afogel and @bar-capsule to all 21 restricted CODEOWNERS lines, giving the Spec workstream leads owner parity with the project leads.

PR #59 is the case that prompted this. It fixed a real defect in response-envelope.json and shipped tests/test_response_envelope.py to prove the fix. @bar-capsule approved it and the merge stayed blocked, because CODEOWNERS granted the spec leads /specification/ and /docs/spec/ but not /tests/, /pyproject.toml, or /uv.lock. A spec lead could approve the schema change and not the test that holds it to its own contract.

That splits one reviewable change across two owner tiers, and it recurs on every spec PR that carries its own coverage, which should be all of them. A narrower grant covering only /tests/ and the packaging files would unblock that exact case and leave the same seam waiting somewhere else, so both handles join every restricted line instead of a chosen subset.

Both already hold maintain on the repository, so the entries take effect on merge rather than failing silently the way the header warns about.

The /.github/ comment claimed those paths warrant admin review. Both new owners hold maintain, so that comment no longer described the list it sat above. It now says what the narrow list is for and points at GOVERNANCE.md for who decides membership.

Type of change

• Specification change (schema, hooks, events, AgBOM)
• Documentation
• Tooling or CI
• Governance (licensing, security policy, contributor docs)

Worth a reviewer's attention

GOVERNANCE.md:35 says a leadership change opens a PR touching GOVERNANCE.md, project.owasp.yaml, and .github/CODEOWNERS together. This PR touches only CODEOWNERS, on the reading that it is not a leadership change: @afogel and @bar-capsule are already Spec workstream leads at GOVERNANCE.md:21, and this widens what they own rather than who they are. project.owasp.yaml carries no role field and caps leaders at five, so nothing there changes either.

The part that deserves a second opinion is the workstream table. It frames each workstream as owning a slice of the standard, and after this the Spec leads own every path in the repository. If that reads as a role change rather than a scope change, GOVERNANCE.md should say so, and I would rather a reviewer make that call than assume it.

Checklist

• Commits are signed off with git commit -s (required by the DCO)
• Prose follows STYLE.md
• uv run mkdocs build --strict passes
• No secrets, tokens, or internal URLs in the diff

Security

This change has security relevance and is worth stating plainly rather than checking a box.

/.github/ is a privilege-escalation surface, because CI runs with write access to the repository. This PR grants two more people the ability to approve changes to it, along with /LICENSE, /SECURITY.md, /LICENSING.md, /NOTICE, and /GOVERNANCE.md. The ruleset still requires an approving review and still blocks self-approval through require_last_push_approval, so no single person can land a workflow change alone. The grant is deliberate and made by the project lead under GOVERNANCE.md:35.