Standardise post-release dev synchronisation

[Jellman86]

Outcome

Post-release synchronization is now an explicit, enforced part of the Optimisarr
release flow. A release cannot quietly leave dev publishing the previous
application version again.

What changed

• document the complete release → tag → dev synchronization sequence
• require a fresh Unreleased section after every release
• validate application, OpenAPI, changelog, and Git tag versions together in CI
• fetch release tags in the documentation job
• add focused tests for stale development versions, missing changelog state,
  OpenAPI drift, and mismatched release tags
• ignore Python bytecode created by the new checks

Root cause

Release 0.2.9 correctly bumped its version on the release branch and main,
but that metadata did not flow back to dev. The dev image therefore
contained the current code while truthfully compiling the stale 0.2.8
application version.

The new guard requires development state to match the newest release tag and
requires release/tag state to match its dated changelog heading. The protected
Docker publish job depends on this check.

Scope and safety

This changes release metadata validation and contributor guidance only. It does
not change media processing, database state, replacement safety, or runtime
configuration.

Validation

• dotnet build Optimisarr.slnx --configuration Release --warnaserror
  — zero warnings
• dotnet test Optimisarr.slnx --configuration Release --no-build
  — 1,487 passed
• python3 -m unittest discover -s scripts/tests -p 'test_*.py'
  — 6 passed
• python3 scripts/check_release_metadata.py
• python3 scripts/check_docs.py
• git diff --check

The existing NVENC harness test requires Bash 4's mapfile, which macOS's
system Bash does not provide; the unchanged test remains part of the Ubuntu CI
documentation job.