fix(release-automation): converge CC regexes — drop top-level security:

[githubrobbi]

Summary

Brings forward the Phase R1b sub-question "keep top-level security: or migrate to chore(security):" and resolves it: top-level security: is no longer an accepted Conventional Commits type anywhere in the toolchain. Security work uses the conventional encoding:

Form	Bump	Changelog section
fix(security): foo	patch (0.x.y → 0.x.y+1)	### Security
chore(security): foo	none	### Security

Top-level security: foo is rejected by the local commit-msg hook, the commitlint workflow, and (after this PR) by both cliff.toml and release-plz.toml's release_commits filter.

Background — the four-regex drift

Regex location	Before this PR	After this PR
scripts/ci/check_commit_subjects.sh (commit-msg + pre-push hook)	11 standard CC types	(unchanged)
.github/workflows/commitlint.yml (PR-title advisory check)	11 standard CC types	(unchanged)
cliff.toml::commit_parsers	11 + top-level security:	11 only
release-plz.toml::release_commits	feat|fix|perf|security	feat|fix|perf

The permissive carve-out in cliff.toml + release-plz.toml was a tolerance for PRs #31, #33, #34 — three early-project commits that used security: as a top-level type before the commit-msg hook was installed. Since the hook landed, no future commit can use that prefix on main, so the carve-outs were dead code preemptively allowing what no longer reaches the codebase.

The dedicated ^fix\(security\) and ^chore\(security\) parsers in cliff.toml already route security work to the ### Security changelog section without needing a non-CC top-level type, so this PR is strictly subtractive for the changelog generator.

Diff (4 files, +34 / −11)

• release-plz.toml — release_commits regex collapses; comment block expanded with the security-encoding convention.
• cliff.toml — drop the ^security(\([a-z0-9-]+\))?: parser and its carve-out comment; updated the section header explaining why only the two scope-based parsers remain.
• CONTRIBUTING.md § Commit message conventions — new "Security commits" paragraph codifying fix(security): + chore(security): as canonical and explicitly stating top-level security: is not allowed. Cross-references the hook + workflow + release-plz filter.
• docs/architecture/release-automation-plan.md — append a deviation log entry "R1b CC-type convergence (early)" documenting decision, rationale, and historical PR linkage.

No code changes. Pure regex + comment + docs convergence.

Validation

• lint-pre-push (Tier 1 fast gate, workspace-parallel) ✅ green in 3s — Bucket 2 (rust/dep/infra) auto-skipped because no source files changed.
• taplo fmt --check on both modified TOML files ✅ green (run as part of lint-fast).
• No CHANGELOG churn — historical PRs security(ci): P1 hardening for the release pipeline #31, security: cargo-geiger + dependabot-review + supply-chain posture doc #33, security: cargo-vet init with 5 upstream imports + weekly refresh workflow #34 entries are not regenerated by git-cliff because they predate the most recent tag.

Plan impact

Brings R1b's enforcement decision forward by ~1 phase. Does not change the R1a → R1b advisory→required scheduling for the commitlint workflow itself; only resolves the orthogonal "should security: be a top-level type" sub-question.

Rollback

Single-file revert restores the carve-outs. No data has moved; no commits are affected (the historical entries in CHANGELOG and release-automation-baseline.md remain unchanged regardless).

Refs

• chore(release-automation): R5 — retire bespoke version-bump tooling #153 (R5 retirement — where the drift was first surfaced during code review of release_commits)