ci(changelog): cz bump regenerates change-log.md with padded trailing whitespace, turning Lint red

[MAfarrag]

Context

The Lint workflow's pre-commit job turns red on main after every release, and then on every PR opened
afterwards, because the release commit regenerates docs/change-log.md with trailing whitespace that the
trailing-whitespace hook rewrites.

This has already happened once and was patched by hand: release: 0.47.0 (#894) made main red, and the
normalization rode along in #895. That fixed the symptom for the current file — it did not fix the generator, so
the next cz bump reintroduces it.

Problem / Current Behaviour

[tool.commitizen] sets update_changelog_on_bump = true with no custom changelog template, so cz bump
regenerates docs/change-log.md from commit bodies verbatim. Conventional-commit bodies in this repo are wrapped
by hand, and commitizen indents the wrapped continuation lines — emitting lines padded with 40-99 trailing
spaces.

The repo's trailing-whitespace hook is configured args: [--markdown-linebreak-ext=md], which preserves an
intentional two-space markdown line break but rewrites anything longer. So the hook reports "files were modified"
and pre-commit exits non-zero.

Measured on 6b435aa9 (release: 0.47.0):

lines ending in a space : 72
trailing-space widths   : [2, 40, 41, 42, 47, 53, 62, 64, 86, 99]

versus the current, hand-normalized file:

lines ending in a space : 71
trailing-space widths   : [2]        # only genuine markdown line breaks

Two consequences beyond the red build:

• Lint runs on pull_request, and actions/checkout builds the PR's merge commit, so every open PR
  inherits main's broken changelog and goes red through no fault of its own.
• The fix is invisible to the contributor: the failure names docs/change-log.md, a file their branch never
  touched.

Affected locations

File	Symbol	Notes
pyproject.toml	[tool.commitizen] (L244-249)	update_changelog_on_bump = true, no template configured
docs/change-log.md	—	the regenerated artefact
.pre-commit-config.yaml	trailing-whitespace (L13-15)	--markdown-linebreak-ext=md; rewrites >2-space padding
.github/workflows/lint.yml	pre-commit job	fails on main and on every PR's merge commit

Steps to Reproduce

cz bump                     # or the release workflow
python -c "d=open('docs/change-log.md','rb').read(); \
  print(sorted({len(l)-len(l.rstrip(b' ')) for l in d.split(b'\n') if l.endswith(b' ')}))"
# -> widths well above 2, e.g. [2, 40, 41, ...]
pre-commit run trailing-whitespace --files docs/change-log.md
# -> Failed: files were modified by this hook

Proposed Solution

Fix it at the generator rather than after each release. Options, roughly in order of preference:

1. Strip the padding during generation — supply a commitizen changelog template (template = "..." under
   [tool.commitizen]) that emits unpadded bodies, or a changelog_message_builder_hook that rstrip()s each
   line of the message body before it is rendered.
2. Normalize as part of the bump — have the release workflow run
   pre-commit run trailing-whitespace --files docs/change-log.md (or a plain sed -i 's/[[:space:]]*$//')
   immediately after cz bump and include the result in the release commit.
3. Exclude the generated file from the hook — add exclude: ^docs/change-log\.md$ to the
   trailing-whitespace hook. Cheapest, but it stops linting a file that is otherwise fine, and hides any future
   whitespace problem in it.

Whichever is chosen, the check should be that a fresh cz bump leaves pre-commit run --all-files green with no
manual step.

Out of Scope

• Rewriting existing changelog history.
• Any other commitizen behaviour (version bumping, tagging, commit parsing).

Effort Estimate

Size: S (half-day)
Rationale: the change itself is small — a template, a hook, or a workflow step — but it needs a real bump to
verify, so the confirmation loop is the slow part.

Definition of Done

• A cz bump produces a docs/change-log.md with no trailing whitespace beyond intentional two-space
  markdown line breaks.
• pre-commit run --all-files is green immediately after a bump, with no manual normalization.
• main and newly opened PRs stay green through a release.
• The chosen approach is recorded next to the commitizen config so the next maintainer does not re-diagnose it.

Related

• release: 0.47.0 #894 — release: 0.47.0, the bump that introduced the padding
• fix(dataset): report every recreate_overviews outcome #895 — carried the hand-normalization that unblocked CI (symptom, not cause)