ci: split prepare and publish into separate release pipelines

- Remove publish steps (release creation, binary build/upload) from the
  Prepare Release workflow; it now stops after committing and pushing the
  tag.
- Add Do Release workflow triggered on v*.*.* tag pushes; reads release
  notes from the tagged changelog section, creates or updates the release,
  builds linux/amd64 and linux/arm64 binaries, uploads assets, then
  smoke-tests both binaries in a follow-on validate job.
- Remove the standalone Action Validation workflow; binary validation now
  runs as a second job in Do Release after the release job succeeds, using
  the exact tag and version just published.
- Update README to document the two-workflow release model and add split
  prepare/publish usage examples for both the composite action and the
  reusable workflows.
- Update changelog unreleased section to reflect the new pipeline split
  and corrected artifact scope (linux/amd64 and linux/arm64 only).

README.md

@@ -56,9 +56,18 @@ By default, `vociferate` reads and writes the release version as the sole conten
 just go-test
 ```
 
+## Release Flow
+
+Releases use two workflows:
+
+- `Prepare Release` runs on demand, updates `release-version` and `changelog.md`, commits those changes back to `main`, and pushes the release tag.
+- `Do Release` runs from the pushed tag, reads the matching changelog section from that tagged revision, creates or updates the release, and uploads prebuilt binaries.
+
+This split matters because release notes must be generated from the tagged commit that already contains the promoted changelog section.
+
 ## Release Artifacts
 
-Releases are prepared through the `Prepare Release` workflow. The workflow creates a release and uploads prebuilt `vociferate` binaries for:
+The tag-driven `Do Release` workflow publishes prebuilt `vociferate` binaries for:
 
 - `linux/amd64`
 - `linux/arm64`
@@ -70,37 +79,108 @@ If a release already exists for the same tag, the workflow updates its release n
 
 You can reuse vociferate in two ways.
 
-Use the composite action directly:
+Use the composite action directly in your prepare workflow:
 
 ```yaml
 - name: Prepare release files
-	uses: git.hrafn.xyz/aether/vociferate@v1.0.0
-	with:
-		version-file: internal/myapp/version/version.go
-		version-pattern: 'const Version = "([^"]+)"'
-		changelog: changelog.md
+  uses: git.hrafn.xyz/aether/vociferate@v1.0.0
+  with:
+    version-file: internal/myapp/version/version.go
+    version-pattern: 'const Version = "([^"]+)"'
+    changelog: changelog.md
 ```
 
 Set `version` only when you want to override the recommended version.
 Pin the composite action to a released tag. It downloads a prebuilt Linux binary from vociferate releases and caches it on the runner, so it does not require installing Go.
 If your repository uses the default plain-text `release-version` file, you can omit `version-file` and `version-pattern` entirely.
 
-Call the reusable release workflow:
+A complete release setup should also split preparation from publication. For example:
 
 ```yaml
-name: Release
+name: Prepare Release
 
 on:
-	workflow_dispatch:
-		inputs:
-			version:
-				description: Optional semantic version override.
-				required: false
+  workflow_dispatch:
+    inputs:
+      version:
+        description: Optional semantic version override.
+        required: false
 
 jobs:
-	release:
-		uses: aether/vociferate/.gitea/workflows/prepare-release.yml@main
-		with:
-			version: ${{ inputs.version }}
-		secrets: inherit
+  prepare:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+
+      - name: Prepare release files
+        id: prepare
+        uses: git.hrafn.xyz/aether/vociferate@v1.0.0
+        with:
+          version: ${{ inputs.version }}
+
+      - name: Commit and push prepared release
+        run: |
+          set -euo pipefail
+          tag="${{ steps.prepare.outputs.version }}"
+          git config user.name "gitea-actions[bot]"
+          git config user.email "gitea-actions[bot]@users.noreply.local"
+          git add changelog.md release-version
+          git commit -m "release: prepare ${tag}"
+          git tag "$tag"
+          git push origin HEAD
+          git push origin "$tag"
+```
+
+Then use a separate tag workflow to publish the release from the tagged revision:
+
+```yaml
+name: Do Release
+
+on:
+  push:
+    tags:
+      - "v*.*.*"
+
+jobs:
+  release:
+    uses: aether/vociferate/.gitea/workflows/do-release.yml@main
+    secrets: inherit
+```
+
+Call the reusable prepare workflow:
+
+```yaml
+name: Prepare Release
+
+on:
+  workflow_dispatch:
+    inputs:
+      version:
+        description: Optional semantic version override.
+        required: false
+
+jobs:
+  release:
+    uses: aether/vociferate/.gitea/workflows/prepare-release.yml@main
+    with:
+      version: ${{ inputs.version }}
+    secrets: inherit
+```
+
+And publish from tags with:
+
+```yaml
+name: Do Release
+
+on:
+  push:
+    tags:
+      - "v*.*.*"
+
+jobs:
+  release:
+    uses: aether/vociferate/.gitea/workflows/do-release.yml@main
+    secrets: inherit
 ```