M8 prep: release workflow + CONTRIBUTING refresh

[roelvangils]

Summary

M8 (1.0 release) infrastructure — the workflow and docs needed before cutting an actual release. Not the release itself; that's a maintainer decision for a follow-up.

What's in here

• `.github/workflows/release.yml` — fires on `v*` tag push. Builds the `dpub` binary for:

  • Linux x86_64 (`x86_64-unknown-linux-gnu`)
  • macOS arm64 (`aarch64-apple-darwin`, with `--features metal` for Whisper GPU)
  • Windows x86_64 (`x86_64-pc-windows-msvc`)

  Each artefact (`dpub--.tar.gz` or `.zip`) is uploaded to a GitHub Release of the same name as the tag. `workflow_dispatch` trigger included so a release can also be cut manually if a tag already exists.

• `CONTRIBUTING.md` — three small fixes:

  • Crate list refreshed: `epub3-writer`, `dpub-convert`, `dpub-validate`, `dpub-audio`, `dpub-whisper`, `dpub-meta`, `dpub-util` are all real now; `dpub-wasm` is the only outstanding one.
  • MSRV: 1.85+ → 1.88 (matches the workspace).
  • `cmake` requirement called out (whisper-rs-sys compiles whisper.cpp from source).
  • New "Releasing" section walks through the tag-driven flow.

Out of scope (intentionally)

• The actual 1.0 release. That's a workspace version bump + CHANGELOG `[Unreleased]` → `[1.0.0]` rename + a tag. Maintainer's decision.
• macOS code signing + notarisation. Requires Apple Developer credentials in repo secrets — deferred until the maintainer is ready to manage that.
• Cargo.io publishing. Most dpub crates are workspace-internal; only `dpub-cli` would make sense to publish, and that's a separate decision.

Test plan

• Workflow YAML syntactically valid (`gh workflow view` will report on push).
• First real run will be on a v0.x.0 tag push when the maintainer cuts the first release. Likely needs at least one debug round (CI YAML always does).
• CONTRIBUTING.md links resolve (Releasing section references the workflow path; README link to Local development table is preserved).