Add VEX generation to Logging Services

## Background

A year ago I [wrote about VEX](https://logging.apache.org/blog/20250728-introduction-to-vex-files.html) and why it's a more useful artifact than our current VDR. This issue tracks actually shipping it.

Briefly, to motivate the work:

- **Our VDR duplicates public data.** Everything in it is already in the public CVE feeds; downstream consumers gain nothing from reading ours.
- **VEX statements add real signal.** They let us tell downstream projects whether a CVE in one of our *dependencies* actually affects users of our components — which is the question downstream maintainers are actually trying to answer.
- **Production can be largely automated.** The [VEX Generation Toolset](https://github.com/vex-generation-toolset) generates candidate statements from SBOMs + callgraph analysis, and gives useful feedback on the quality of our SBOM data as a side effect.
- **The volume is low.** Vulnerabilities in our upstream dependencies typically surface as a Dependabot security PR (recognizable by the "You can disable automated security fix PRs…" footer even without Security Alerts access). One CVE corresponds to one VEX statement. This is not a large ongoing burden.

## Roadmap

- [x] **Publish SBOMs to `callgraph-metadata` post-release.** Add a workflow step that uploads the release SBOMs to the [`vex-generation-toolset/callgraph-metadata`](https://github.com/vex-generation-toolset/callgraph-metadata) repo, so callgraphs are extracted from our JARs and dependencies are monitored for CVEs upstream. vex-generation-toolset/callgraph-metadata#296
- [x] **Store each VEX statement in its own file.** Enables clean separation between CVEs in our own components (`metadata.component == vulnerability.affects`) and CVEs in third-party components. Done for existing VDR entries in #26.
- [ ] **Add vulnerability-monitoring + VEX-generation workflow.** A scheduled workflow that monitors our published SBOMs for new CVEs and opens a PR with a draft VEX statement for each one, ready for a maintainer to review and complete the `justification` / `response` fields.
- [ ] **Document the VEX authoring process** in the contributor guide.
- [ ] **Publish VEX statements alongside releases**: the path / URL scheme for downstream consumers to fetch them should be decided and documented.

Review the completed SBOM upload work and existing VDR files from #26, then trace the release workflow and the contributor guide. The finished work needs scheduled vulnerability monitoring, draft VEX pull requests, authoring documentation, and a decided URL scheme for publishing VEX statements alongside releases.

Written by the indexing model from the issue text.