Phase 4 slice 1: workflow format, validated at the push that introduces it

Phase 4 slice 1: workflow format, validated at the push that introduces it

.vole/workflows/*.yaml is parsed in pre-receive for any push that touches it, so a
broken workflow fails the push that added it, naming the file and every problem in
it. The alternative — accepting the file and discovering months later that it
never ran — is the failure this exists to prevent.

  version: 1
  on: {push: {branches: [main, "release/*"]}}   # globs, default: every branch
  jobs: {test: {steps: [{run: go test ./..., timeout: 20m}]}}

Strict by construction:

- Unknown keys are rejected rather than ignored, so `runs-on:` or a typo'd `setps:`
  cannot silently do nothing.
- Every problem is reported in one rejection, not the first one only: a person
  fixes the file once instead of once per push.
- Job names, step bodies, timeouts (default 10m, cap 1h) and the directory layout
  are all checked, including files that are not .yaml/.yml and nested directories.
- The validator is in internal/workflow and `vole workflow check` runs the same
  code, so client and server cannot disagree about what is valid.

Validation is scoped by a diff: a push that does not touch the workflow directory
costs one `git diff` and nothing else.

Adds gopkg.in/yaml.v3 (already in the module cache). Nothing executes yet — the
queue, runner and status reporting are the next slice, and the README says so
plainly rather than implying CI runs.

Verified on a live instance: pushing a workflow with a step that runs nothing and a
9h timeout is rejected with both problems named; the corrected file pushes and
`vole workflow list` reports `ci.yaml  on main,release/*  test(2 steps)`.