[CI] Clarify whether `PR Validation Success` should be a required status check

The `main-branch-protection` ruleset requires six status check contexts. Five of them are jobs inside `pr-validation.yml`, but that workflow's `PR Validation Success` aggregator is not one of them. Two repository artifacts state or assume that the aggregator is the gate. This issue asks whether the current required set is deliberate, because the answer decides whether the fix is a documentation correction or a ruleset change.

## Current state

Verified 2026-08-24 against the live API.

Required contexts on `main` (ruleset `main-branch-protection`, id `9453100`, `enforcement: active`):

| Context | Origin |
|---|---|
| `Spell Check / Spell Check` | `pr-validation.yml` (reusable call) |
| `Frontmatter Validation / Validate Markdown Frontmatter` | `pr-validation.yml` (reusable call) |
| `Markdown Lint / Markdown Lint` | `pr-validation.yml` (reusable call) |
| `PowerShell Lint / PowerShell Lint` | `pr-validation.yml` (reusable call) |
| `Table Format Check / Table Format Check` | `pr-validation.yml` (reusable call) |
| `CodeQL Security Analysis / CodeQL Analysis (actions)` | `codeql-analysis.yml` |

So `pr-validation.yml` does gate merge, through those five jobs.

What it does not gate through is `pr-validation-success` (display name `PR Validation Success`), which `needs` roughly thirty jobs and is not a required context. The jobs it aggregates but which are absent from the table above therefore do not block a merge on their own. Those include dependency pinning, npm and pip audit, eval validation, pytest, Pester, Docusaurus tests, plugin validation, and skill validation.

Reproduce with:

```bash
gh api repos/microsoft/hve-core/rules/branches/main \
--jq '.[] | select(.type=="required_status_checks") | .parameters.required_status_checks[].context'
```

## Artifacts that disagree with the ruleset

1. `.github/instructions/workflows.instructions.md` states that `pr-validation.yml` "exposes a single `pr-validation-success` aggregator job as the required status check that gates merge." The aggregator is not a required context; five individual jobs are. This file's `applyTo` is `**/.github/workflows/*.yml`, so it loads into agent context whenever a workflow is edited, which gives the inaccuracy an unusually wide blast radius.

2. ADR 0002 (status `accepted`) states in its Confirmation section that the evaluation matrix "runs the `evals/` suites in PR CI and blocks merge on authoritative-gate failures." `eval-validation` is not a required context and reaches the merge gate only through the non-required aggregator.

## The question

Is the current required set deliberate, or did the aggregator get dropped when `main` moved from classic branch protection to the ruleset?

* If deliberate, both artifacts need correcting, and ADR 0002's Confirmation clause needs a mechanism that actually holds.
* If not deliberate, the ruleset needs `PR Validation Success` added as a required context, and both artifacts are already describing the intended design.

Intent could not be determined from the repository or the platform. No ADR records the branch-protection or ruleset decision, and both `rulesets/{id}/history` and the organization audit log require admin access, which is above the `maintain` permission level available here.

## Acceptance Criteria

- [ ] A maintainer with admin access states whether `PR Validation Success` is intended to be a required status check
- [ ] If it is intended, the `main-branch-protection` ruleset is updated to require that context
- [ ] If it is not intended, `workflows.instructions.md` is corrected to describe the six required contexts rather than the aggregator
- [ ] ADR 0002's Confirmation section is reconciled with whichever answer holds
- [ ] The branch-protection documentation continues to match the live ruleset

## Related

* Context: #2755 (branch-protection documentation reconciled against the same ruleset)
* Context: #2461 (accepted stale-review-dismissal gap in the same ruleset)

## Notes

Verification only; this issue proposes no change on its own. It was raised while reconciling the branch-protection pages in #2755, where the same class of drift was found in user-facing documentation.