docs(054): MCP security gateway hardening — umbrella spec (5 tracks) (#521)

* fix(053): drop duplicate MCP registry workflow; point docs at existing release.yml job

release.yml already has an 'mcp-registry' job that publishes server.json on every
tag via keyless GitHub OIDC (continue-on-error) — it has shipped 44 versions to
registry.modelcontextprotocol.io. The publish-mcp-registry.yml added in #517 was a
redundant duplicate that would have thrown 'cannot publish duplicate version' on
every release. Removes it and corrects docs/mcp-registry-publishing.md to reference
the existing automation instead of claiming publishing was manual.

* docs(054): MCP security gateway hardening — umbrella spec (5 tracks)

Related #N/A

Umbrella spec decomposing the 'reference OSS MCP security gateway' roadmap into
5 independently-shippable tracks (output-schema validation, output sanitisation
enforcement, per-tool/per-arg capability ACLs, TOFU pinning hardening, EU AI Act
Article 12-aligned tamper-evident audit logging), each grounded in a gap analysis
against existing features (Specs 026/028/032/035, activity log).

Author: Dumbris

specs/054-mcp-security-gateway/checklists/requirements.md

@@ -0,0 +1,36 @@
+# Specification Quality Checklist: MCP Security Gateway Hardening
+
+**Purpose**: Validate specification completeness and quality before proceeding to planning
+**Created**: 2026-05-23
+**Feature**: [spec.md](../spec.md)
+
+## Content Quality
+
+- [x] No implementation details (languages, frameworks, APIs)
+  - Note: file:line pointers appear in a clearly-labelled "Context" section as gap-analysis grounding for an umbrella eng spec; FRs and success criteria themselves stay behavioural/technology-agnostic.
+- [x] Focused on user value and business needs
+- [x] Written for non-technical stakeholders (user stories framed as operator outcomes)
+- [x] All mandatory sections completed
+
+## Requirement Completeness
+
+- [x] No [NEEDS CLARIFICATION] markers remain (informed assumptions documented in Assumptions)
+- [x] Requirements are testable and unambiguous (each FR has a verifiable behaviour; each story has an Independent Test)
+- [x] Success criteria are measurable (SC-001…SC-008, mostly 100%/detection-rate framed)
+- [x] Success criteria are technology-agnostic
+- [x] All acceptance scenarios are defined (Given/When/Then per track)
+- [x] Edge cases are identified (per-track, incl. the ContextForge #4042 trap and async-vs-hash-chain)
+- [x] Scope is clearly bounded (5 tracks + Non-Goals + "docs restructure is a separate spec")
+- [x] Dependencies and assumptions identified (Context section maps each track to existing Spec; Assumptions section)
+
+## Feature Readiness
+
+- [x] All functional requirements have clear acceptance criteria
+- [x] User scenarios cover primary flows (one prioritised story per track A–E)
+- [x] Feature meets measurable outcomes defined in Success Criteria
+- [x] No implementation details leak into the requirements/success sections
+
+## Notes
+
+- This is an **umbrella spec**; each track should get its own `/speckit.plan` (and `/speckit.tasks`) when implementation starts. Recommend running `/speckit.plan` per track (A first) rather than for the whole umbrella at once.
+- Validation passed on first iteration; no [NEEDS CLARIFICATION] markers.