ci: validate templates before building (Task 2B, phase 3)

[0xSagaCity]

Stacked on #6 (phase 2), which adds the validate:templates script this workflow step invokes. Three lines of YAML.

Why

deploy.yml builds and deploys to GitHub Pages on every push to master with no template check. Today a broken template either fails the build with a webpack-shaped error that doesn't name the template, or — for a field typo, which webpack cannot see at all — deploys successfully and renders wrong.

What

One step in the existing build job, between Install dependencies and Build the project:

      - name: Validate templates
        run: npm run validate:templates

Placement is the entire design:

• Same job, so it reuses the npm ci that already ran. A separate job would repeat a full install to save ~70ms of validation.
• Before the build, so a failure reads as your template is wrong rather than the deploy broke, and no artifact is produced from a tree known to be invalid.
• Default severity, not --strict, so an unknown-field warning cannot block a deploy. The generated contract has been incomplete before, and a stale contract blocking a forker's deploy is exactly the failure 2A's severity split exists to avoid. Watch mode (phase 4, feat(webpack): surface template diagnostics in the dev-server overlay (Task 2B, phase 4) #8) is where field typos get promoted, because there they cost nothing.

npm run propagates the non-zero exit, which is 2A's R7 doing the actual gating — nothing here re-implements it.

The trigger list is deliberately unchanged

push: [master] and workflow_dispatch stay as they are. Adding pull_request was considered and declined at the plan's approval gate: forkers of a sandbox commit straight to master, so push is already the moment that matters, and a new CI surface on a public repo buys feedback most contributors here never see.

The consequence, stated plainly: a fork PR gets no template feedback until merge. If that is ever revisited, this step needs no edit — only the trigger list, plus an if: github.event_name == 'push' guard on the deploy job.

Verification

S37 (the whole content of this phase) — asserted by parsing the workflow, since ordering is the change and a green CI run proves nothing about a broken template:

Assertion	Result
step order Install dependencies(2) → Validate templates(3) → Build the project(4)	PASS
runs npm run validate:templates	PASS
no --strict flag	PASS
lives in the build job (reuses npm ci)	PASS
pull_request absent from triggers	PASS
YAML parses; build job steps intact	PASS

S38 is not executed, deliberately. It calls for pushing a broken template and watching a real Actions run. This workflow triggers only on push: [master] and workflow_dispatch, so a scratch branch does not trigger it at all — the only ways to run it are pushing to master or dispatching against a ref, and both deploy this public sandbox to GitHub Pages from an unmerged branch. I am not doing that unilaterally. Worth running once this and #6 merge; the step's behaviour is otherwise fully determined by the npm run exit code, which phase 2 verified directly (clean exit 0, broken exit 1).