GeezerVison

Add an optional `--vex <path>` argument to `apply` and `scan`. On a
successful run, the command writes an OpenVEX 0.2.0 document to that path
using the same engine as the standalone `vex` command, so a single
invocation can both apply/scan patches and emit the attestation — the
natural shape for CI and bot workflows.

Core refactor: extract the product-resolve -> verify -> build -> serialize
-> write -> telemetry pipeline out of `vex::run` into reusable
`generate_vex` / `generate_vex_from_manifest_path` helpers (plain
VexBuildParams / VexWriteSummary / VexGenError types). The standalone `vex`
command now calls this helper with no behavior change.

Embedded contract:
- `--vex` is the trigger; `--vex-product` / `--vex-no-verify` /
  `--vex-doc-id` / `--vex-compact` mirror the standalone knobs (namespaced
  to avoid colliding with apply's --force vocabulary; reuse SOCKET_VEX_*).
- Always written to the file, never stdout, so it never races --json.
- Fail-the-command: a requested-but-failed VEX flips the exit code even
  when the apply/scan itself succeeded, surfacing the error in the JSON
  envelope (apply) / result (scan) with a stable code.
- Built from the post-run manifest, verified against on-disk state;
  generated for real applies, --dry-run, and read-only scans alike.
- JSON success adds a top-level `vex` summary { path, statements, format }.

Tests: new e2e_embedded_vex.rs (apply parity, envelope field, fail path,
scan no-verify success, scan verify-failure error); parse-test coverage in
cli_parse_{apply,scan}; update CLI_CONTRACT.md.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

Add an Unreleased "Added" changelog entry, document the `--vex` / `--vex-*`
flags in the apply & scan README tables with examples, and add an
"Inline VEX on apply / scan" subsection covering the fail-the-command
contract and JSON summary surface.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

Add `scripts/rollover-changelog.sh` and a post-publish `changelog-rollover`
job. After every artifact publishes, the job promotes `## [Unreleased]` to
`## [<version>] — <date>` and leaves a fresh empty `[Unreleased]` for the
next cycle, then commits it back to the release branch (`[skip ci]`).

The helper is idempotent and runs after publish, so it never fails the
release: it's a no-op when a `## [<version>]` heading was written by hand or
when `[Unreleased]` is empty, leaving the file byte-identical so there's
nothing to commit.

To make the new flow usable end-to-end, the pre-publish version-check now
accepts a non-empty `[Unreleased]` section as valid release notes (in
addition to an explicit `## [X.Y.Z]` heading), so maintainers can just add
entries under `[Unreleased]` and let the rollover stamp them.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

Empty commit to re-trigger the CI workflow — the previous push
(a7ad4cf) did not fire a pull_request run.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

The Audit GHA Workflows check (zizmor) flagged a High template-injection:
`${{ github.ref_name }}` expanded directly inside the push `run:` block can
inject attacker-controllable code via a crafted branch name. Pass workflow
contexts (`github.ref_name`, `needs.version.outputs.version`) through `env:`
and reference them as shell variables instead.

Verified clean with `zizmor .github --gh-token <tok> --min-severity medium`
(the exact CI invocation): "No findings to report."

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>