chore(release): promote changelog into [4.0.5]

[bpamiri]

Release prep for 4.0.5 — a packaging hotfix on top of the (unannounced) 4.0.4.

Promotes two changelog.d fragments into [4.0.5]:

• Added: Linux .deb/.rpm are now arch-independent → install on arm64.
• Fixed: RHEL/Fedora Java-detection (the .rpm now starts on Rocky/Fedora).

The promote tooling (fixed in #3219) emits the correct single-hash # [4.0.5](tag) => date header + --- separator; verified release.yml's awk extracts the section with zero bleed into 4.0.4.

🤖 Generated with Claude Code

[wheels-bot]

Wheels Bot — Reviewer

TL;DR — This is the 4.0.5 release-promotion PR: it inserts a new [4.0.5] => 2026-06-19 section into CHANGELOG.md with one Added (arch-independent Linux .deb/.rpm + arm64) and one Fixed (RHEL-family Java-21 detection) bullet, both crediting #3223. The diff is a clean, accurate, well-formed 12-line changelog promotion. Verdict: approve.

Conventions

• The direct CHANGELOG.md edit is correct here, not a finding. CLAUDE.md routes fix/feat PRs through changelog.d/ fragments, but explicitly carves out release cut: "tools/changelog-promote.sh <version> assembles fragments … into the new version section." This is that promotion, and the [Unreleased] block is correctly left intact with its "Do not add entries here" placeholder.
• New section format matches the existing convention exactly — [4.0.5](…/tag/v4.0.5) => 2026-06-19 mirrors the [4.0.4](…) => 2026-06-18 shape, with --- separators on both sides and newest-first ordering (inserted above 4.0.4). Date 2026-06-19 is today and sequential after 4.0.4's 2026-06-18.

Correctness

• Content accurately reflects #3223 (commit edb4071e4): arch-independent packages / arm64 support → Added; RHEL/Fedora Java-21 probe fix → Fixed. Both bullets cite (#3223). No duplication — develop's CHANGELOG did not already carry a 4.0.5 section, so the hunk inserts cleanly.

Commits

• chore(release): assemble changelog.d fragments into [4.0.5] — valid type/scope, subject ≤ 100 chars, DCO sign-off present.
• Minor, non-blocking: the commit subject and PR body say "assemble changelog.d fragments," but changelog.d/ held only README.md at the time (no fragment .md files) — the content was entered directly rather than promoted from fragments. The resulting CHANGELOG is correct either way; just a cosmetic wording mismatch with the mechanism, no action required.

No Correctness, Cross-engine, Security, or commitlint findings. Docs-only release prep — nothing to test.