📖 [Docs]: Specification requirement anchors render correctly (#449)

The Process-PSModule specification now uses markdownlint-compatible
explicit anchors for every functional and non-functional requirement, so
direct links to FR1-FR6 and NFR1-NFR5 remain reliable.

## Changed: Requirement anchors render reliably

All 11 requirement headings now use the canonical `{#id}` syntax.
Requirement identifiers, heading text, link targets, and documented
behavior are unchanged.

---
<details>
<summary>Technical details</summary>

- Normalized the 11 explicit anchors in
`docs/content/Modules/Process-PSModule/specification/spec.md` from `{
#id }` to `{#id}`.
- Backward compatibility: all existing anchor identifiers are preserved.
- Standards and framework alignment:

| Changed surface | Standards checked | Framework docs checked | Result
|
| --- | --- | --- | --- |
| `docs/content/Modules/Process-PSModule/specification/spec.md` |
Markdownlint MD051 anchor syntax | Process-PSModule documentation
structure | Aligned |

- Issue convergence sweep: this focused documentation-only diff fully
carries forward the still-applicable Process documentation portion of
MSXOrg/docs#144; no additional issues are satisfied.

</details>

<details>
<summary>Relevant issues (or links)</summary>

- MSXOrg/docs#144

</details>

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Author: MariusStorhaug

docs/content/specification/spec.md

@@ -25,53 +25,53 @@ Applies to any PowerShell module in the PSModule ecosystem that produces a versi
 
 ### Functional Requirements
 
-### FR1 — Build the module from source { #fr1 }
+### FR1 — Build the module from source {#fr1}
 
 The pipeline MUST compile the PowerShell module source code into a module artifact, stamping it with the resolved semantic version and making it available for downstream testing and publication.
 
-### FR2 — Run cross-platform tests { #fr2 }
+### FR2 — Run cross-platform tests {#fr2}
 
 The pipeline MUST execute the module's test suites against multiple platforms — at minimum Windows, Linux, and macOS — and fail the build if any platform's tests fail. Tests MUST include source-code validation (style, standards), framework tests (module structure, common issues), and module-local tests (user-written Pester tests).
 
-### FR3 — Enforce code quality and coverage gates { #fr3 }
+### FR3 — Enforce code quality and coverage gates {#fr3}
 
 The pipeline MUST measure and enforce code coverage thresholds and static-analysis results. A build MUST NOT proceed to publication if quality or coverage targets are missed; the gate MUST prevent merge unless explicitly overridden by a label.
 
-### FR4 — Generate and publish documentation { #fr4 }
+### FR4 — Generate and publish documentation {#fr4}
 
 The pipeline MUST generate module documentation from the source (cmdlet help, README, schema) and publish it to a static documentation site. Documentation MUST be versioned and deployable alongside the module release.
 
-### FR5 — Support label-driven versioning and publication { #fr5 }
+### FR5 — Support label-driven versioning and publication {#fr5}
 
 The pipeline MUST read pull-request labels (`Major`, `Minor`, `Patch`, `Prerelease`, `NoRelease`) to decide the
 semantic-version bump when the merged pull request exactly matches a default-branch push. It MUST compute the next
 version automatically, never reading or writing a hand-edited version file. An important push to the release branch
 MUST trigger publication to the PowerShell Gallery and documentation site; a prerelease label MUST result in a
 prerelease version available for testing before stable release.
 
-### FR6 — Produce immutable, linkable releases { #fr6 }
+### FR6 — Produce immutable, linkable releases {#fr6}
 
 Each publication MUST produce a GitHub Release, a git tag, and a PowerShell Gallery package version — all linked and versioned together so they are discoverable and pinnable for consumers.
 
 ### Non-Functional Requirements
 
-### NFR1 — Semantic versioning compliance { #nfr1 }
+### NFR1 — Semantic versioning compliance {#nfr1}
 
 Versions MUST follow [SemVer 2.0.0](https://semver.org/) (`vMAJOR.MINOR.PATCH` or `vMAJOR.MINOR.PATCH-prerelease.N`). Breaking changes MUST increment `MAJOR`; new functionality MUST increment `MINOR`; bugfixes MUST increment `PATCH`. Prerelease versions MUST be obtainable but not promoted as the latest stable release.
 
-### NFR2 — Serialized releases { #nfr2 }
+### NFR2 — Serialized releases {#nfr2}
 
 Only one release process MUST run against a given version of the codebase at a time. Concurrent releases to the same ref MUST be prevented, so the tag, version counter, and published artifact remain consistent.
 
-### NFR3 — Single production authority { #nfr3 }
+### NFR3 — Single production authority {#nfr3}
 
 Exactly one branch (typically `main`) MUST be authorized to publish stable releases. All other release branches MUST publish only prerelease versions. This ensures consumers have one unambiguous latest stable version.
 
-### NFR4 — Rapid feedback on failure { #nfr4 }
+### NFR4 — Rapid feedback on failure {#nfr4}
 
 Pipeline failures MUST be visible in the pull request and block merge. Contributors MUST know within minutes whether their changes pass quality and test gates, not hours or days later.
 
-### NFR5 — Reproducible and auditable { #nfr5 }
+### NFR5 — Reproducible and auditable {#nfr5}
 
 The entire pipeline and its decisions MUST be stored in git, so the build is reproducible and auditable from the commit alone. No external configuration, API calls, or out-of-band decisions.