Adopt release-plz for version coordination + changelog automation

Replace the manual version-coordination workflow (see related
version-coordination policy issue) with \`release-plz\`, which
automates:

- Detecting which crates changed since the last release (via
\`cargo metadata\` + git diff).
- Bumping versions per the workspace's package manifest.
- Generating per-crate CHANGELOG entries from Conventional
Commits subjects.
- Opening a release PR that, when merged, tags and triggers the
existing \`release.yml\` workflow.

## What

1. Add the \`release-plz\` GitHub Action to
\`.github/workflows/release-plz.yml\`. Schedule: weekly
(Mondays) + on workflow_dispatch.
2. Configure \`release-plz\` in \`release-plz.toml\`:
- tag name: \`voxora-X.Y.Z\` (single per release, no
per-crate tags for new releases — the existing per-crate
tags are the migration artifact; we keep them for
backwards compat but stop creating new ones).
- changelog path: per-crate \`CHANGELOG.md\`.
- conventional commits parsing enabled.
3. Add a CI job that runs \`cargo release-plz check\` to verify
the configuration parses.
4. Update \`AGENTS.md\` to point at release-plz for the release
flow.

## Why

Currently:

- Bumping 11 crates' versions is a hand-edited step that
touches 22+ lines of \`Cargo.toml\` files per release. Easy to
miss a crate.
- CHANGELOG entries are written by hand and historically have
had attribution errors (the F2 fix-PR had to rewrite
CHANGELOGs that misattributed 0.1.x work to 0.2.0).
- \`release-plz\` is the standard tool for this in the Rust
ecosystem; projects like \`ratatui\`, \`bevy\` (some subcrates),
and \`tokio\`-adjacent projects use it.

## Acceptance

- \`cargo release-plz release\` (dry-run) generates the expected
per-crate CHANGELOG entries and version bumps for the next
release.
- A test release-plz run on a fake \`chore(release): ...\` commit
produces a release PR with the right contents.
- The existing manual \`CONTRIBUTING.md\` \"Release process\"
section is updated to point at release-plz.

## Out of scope

- Replacing the existing \`release.yml\` with a release-plz
template. The two can coexist: release-plz creates the release
PR; the merged PR triggers the existing tag-validation +
cold-build + GitHub Release job.

Start by reading the existing .github/workflows/release.yml, workspace Cargo.toml files, AGENTS.md, and CONTRIBUTING.md's Release process. Then verify that release-plz.toml and .github/workflows/release-plz.yml cover the stated schedule, configuration checks, changelog paths, and tag behavior. Done means the dry-run and fake release commit produce the expected version bumps, changelogs, and release PR.

Scritto dal modello di indicizzazione a partire dal testo della issue.