Plugin pack ships branch-protection contexts that don't match CI workflow job names — merges blocked even when all checks pass

## Summary

The vsdd-factory plugin pack ships **two assets from the same pack** that disagree on names:

1. **Branch-protection configuration** (or the gh-api PUT call emitted by the orchestrator/devops-engineer at P3-01) declares `required_status_checks.contexts` as the short job-ids: `["fmt", "clippy", "build", "test", "deny"]`.
2. **CI workflow** (`.github/workflows/ci.yml` from the pack) sets `jobs..name:` to human-readable labels: `Format check`, `Clippy`, `Build`, `Test`, `Dependency audit (cargo-deny)`.

GitHub matches required-contexts by the **check-run name** (which is `jobs..name:` when set, falling back to `` only when `name:` is absent). With both shipped together, the workflow emits check-runs named `Format check / Clippy / Build / Test / Dependency audit (cargo-deny)`, while protection waits for contexts named `fmt / clippy / build / test / deny`. The required contexts never resolve, and `mergeStateStatus: BLOCKED` is permanent — even with all 5 (or 6) CI checks succeeding. `gh pr merge --admin` returns HTTP 405 \"N of N required status checks are expected\".

## Concrete evidence (ArcavenAE/akey, this session, PR #8)

\`\`\`yaml
# .github/workflows/ci.yml (shipped by vsdd-factory plugin pack)
jobs:
fmt:
name: Format check
clippy:
name: Clippy
build:
name: Build
test:
name: Test
deny:
name: Dependency audit (cargo-deny)
\`\`\`

Protection (per the orchestrator's P3-01 PUT payload, recorded verbatim in \`.factory/cycles/v0.1.0-phase1-spec/burst-log.md\` line ~2475):

\`\`\`json
{ \"required_status_checks\": { \"strict\": true,
\"contexts\": [\"fmt\", \"clippy\", \"build\", \"test\", \"deny\"] } }
\`\`\`

Result on PR #8 with every check SUCCESS: `mergeStateStatus: BLOCKED`, admin-bypass merge refused with \"5 of 5 required status checks are expected\".

## Root cause hypothesis

In the engine, the two assets live in different places and were never cross-validated:

- Workflow template: `agents/devops-engineer/templates/ci.yml` (or wherever the rust/generic pack stores it). Authored with friendly `name:` values for human readability in the GitHub UI.
- Branch-protection PUT payload: hard-coded into the orchestrator-skill P3-01 step (or devops-engineer's protection-apply step) as the short job-id list.

There is no lint, smoke test, or template-build step in the engine that asserts the two assets agree on names.

## Suggested fix shape

Pick ONE source of truth and derive the other, then add a CI gate in the engine repo:

- **Option A (preferred):** Remove `name:` overrides from `ci.yml` so each check-run name is just the job-id (`fmt`, `clippy`, etc.); these match the protection contexts. Cheapest fix, least informative GitHub UI.
- **Option B:** Keep the friendly `name:` values, and change the protection PUT payload (and any orchestrator-skill prompt mentioning the contexts) to use the friendly names verbatim.
- **Either way:** Add a unit test or pre-commit lint to the pack repo that parses `ci.yml`, extracts the effective check-run names per job (`name:` when set else ``), and asserts the set equals the contexts in the protection-apply payload.

## Severity

**P0 — blocks all merges** for any product that ships pack-defaults and enables branch protection. Visible end state for the user is a fully-green PR that cannot be merged, with a misleading admin-bypass refusal message.

## Cross-references

- #343 (PG-1) orchestrator yields after state-manager close-out
- #346 (PG-5) gate-template 1-approver default deadlocks autonomous pipelines
- #347 (PG-6) yields on external-wait without scheduling a wake
- #348 (PG-7) wrong endpoint for protection verification (private non-Enterprise org repos)

This is a fifth, distinct class — **two pack assets disagree on names at delivery time, with no co-validation gate.**