Move the flags that clap flattens into every subcommand into a single
"Global Options" section (with env vars and precedence), and trim each
command's table down to its command-specific flags. Also fixes a few
stale entries (no `-d` short for `--dry-run`, repair's download-mode
default is `diff` not `file`) and documents the previously-undocumented
`--all-releases`, `--proxy-url`, `--lock-timeout`, `--break-lock`,
`--debug`, and `--no-telemetry` flags.

Adds a `vex` command entry and an "OpenVEX attestations" section
covering product auto-detection, output channels, and how to feed the
document into Grype/Trivy/vexctl.

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* feat(apply,scan): generate OpenVEX document inline via --vex

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) <noreply@anthropic.com>

* docs: changelog + README for inline --vex on apply/scan

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) <noreply@anthropic.com>

* ci(release): auto-roll CHANGELOG [Unreleased] over after publish

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) <noreply@anthropic.com>

* chore: nudge CI

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) <noreply@anthropic.com>

* ci(release): fix zizmor template-injection in changelog-rollover

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) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Bumps [tar](https://github.com/composefs/tar-rs) from 0.4.45 to 0.4.46.
- [Release notes](https://github.com/composefs/tar-rs/releases)
- [Commits](composefs/tar-rs@0.4.45...0.4.46)

---
updated-dependencies:
- dependency-name: tar
  dependency-version: 0.4.46
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

Bump 3.2.0 -> 3.3.0 (minor) for the inline OpenVEX feature already staged
under CHANGELOG `## [Unreleased]`. Synced via scripts/version-sync.sh across
Cargo.toml (workspace version + core dep pin), Cargo.lock, all npm packages
(main + platform shims + lockfile), and pypi/pyproject.toml.

The Release workflow reads this version from Cargo.toml; once merged it can be
dispatched to publish v3.3.0 and roll the CHANGELOG over.

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>