fix: pin reviewed workflow file surface

[sylvesterkaczmarek]

Summary

Make the repository's CI policy reject unreviewed GitHub Actions workflow files instead of validating only the known protected workflow subset.

Problem

script/validate-locks performs unusually strict structural validation of Fence's reviewed workflows, but it does not assert the complete filename set under .github/workflows.

The validator derives the set of workflows containing pull_request: and requires that set to equal the reviewed PR workflow list. It then applies exact contracts to specific known workflow names. A newly added push-only workflow does not change that PR-workflow set and is not covered by any of the named exact contracts.

That leaves a policy gap: a new workflow file can exist outside the reviewed workflow surface even though Fence treats workflow permissions, runners, commands, and immutable dependencies as part of its supply-chain boundary.

Evidence / reproduction

• The current repository contains exactly nine workflow files: acceptance.yml, action-acceptance-ubuntu-latest.yml, action-acceptance.yml, action-drift-canary.yml, build.yml, integration.yml, lint.yml, release.yml, and test.yml.
• validate_ci_evidence enumerates every *.yml/*.yaml file, but its global checks only require one explicit top-level on: mapping and unquoted structural keys.
• It separately requires the exact set of workflows that contain pull_request:, so an added push-only workflow leaves that assertion unchanged.
• Read-only permission enforcement is applied to the derived pull-request workflow set; the later exact job/step contracts are keyed to known workflow filenames.
• There is no assertion that set(workflow_sources) equals the reviewed nine-file workflow surface.
• Minimal reproduction on the base validator: add .github/workflows/unreviewed.yml with an explicit on: push trigger, a syntactically ordinary job, and permissions: contents: write. Because it has no pull_request: trigger and no known workflow name, it is outside the exact protected-workflow contracts.
• The new validator self-test proves both directions: an extra workflow is rejected, and removal of a reviewed workflow is rejected.

Change

• define the exact nine-file reviewed workflow surface in a small dedicated validator
• require every reviewed entry to be a regular non-symlink file
• reject both unexpected and missing workflow files
• run the validator and its focused self-test from script/lint

This does not change any existing workflow, permission, trigger, runner, or command. It makes addition/removal of a workflow an explicit reviewed policy change rather than an implicit extension of the CI surface.