[BUG] CHANGELOG regenerates with soothfast-bot's own commits in it

[Verdenroz]

What happened

The generated CHANGELOG.md lists soothfast-bot's own regeneration commits as changelog entries. They are commits that exist only to land generated files, not changes to the project, so they should be excluded from the changelog entirely.

Current CHANGELOG.md, under ## Unreleased (draft vs v3.0.0) → ### 🔧 Internal:

- Regenerate derived artifacts (#457)
- Regenerate derived artifacts (#454)

Both are soothfast-bot[bot] commits. Expected: neither appears.

There is a mild feedback loop in this too — the bot regenerates CHANGELOG.md, that regeneration lands as its own commit, and that commit is then eligible to show up in a later regeneration.

Environment

• Component: CI / changelog generation (not library, server, CLI, or MCP)
• Version: cargo-soothfast v0.3.1, pinned at .github/workflows/soothfast.yml:106 (Verdenroz/soothfast@80b18d8)
• Config: soothfast.toml has no [changelog] section, so commit filtering is whatever the action defaults to

Reproduction

1. Merge any PR to master.
2. The gate job in .github/workflows/soothfast.yml regenerates CHANGELOG.md and lands it on bot/soothfast-update as chore: regenerate soothfast outputs.
3. Merge a second PR.
4. The next regeneration includes the bot's own commits from step 2 in the Unreleased section.

Or just read the two Regenerate derived artifacts lines in CHANGELOG.md at 35b3068a.

Additional context

The fix probably belongs in filtering rather than in commit conventions — the bot's commits are already conventionally typed (chore:), so a type-based filter alone will not catch them while letting real chore: work through. Filtering on author (soothfast-bot[bot], *[bot]) or on the bot's branch names (bot/soothfast-update, bot/derived-artifacts) is more likely to be the right cut.

Related history, already fixed and not part of this: on Sep 1 the changelog regenerated four times in five minutes (#467–#470). The actor guard added in #472 stopped that loop. This issue is about what lands in the file, not how often it lands.

[Verdenroz]

Reopening: #491 bumped the pinned action to v0.3.2, but that is not the pin that decides which CLI runs, so the filter never executed.

Evidence

The first bot regeneration after the bump, #492, re-added the entries this issue is about:

 ### 🔧 Internal

+- Bump soothfast to v0.3.2 (#491)
+- Stop gating generated specs and SDKs at PR time (#487)
+- Collapse the two bot regeneration commits into one (#486)
+- Regenerate derived artifacts (#489)
+- Regenerate soothfast outputs (#488)
 - Regenerate derived artifacts (#478)

Root cause

action.yml:136 resolves the CLI version from the lockfile, not from the action's own ref:

version=$(grep -A1 '^name = "soothfast"$' "$INPUT_LOCKFILE" | grep '^version' | cut -d'"' -f2)

Cargo.lock on master pins soothfast 0.3.0, and no workflow passes a version: input to the action. So CI installs cargo-soothfast 0.3.0 — two releases behind the action pin. DEFAULT_BOT_AUTHOR and the %an-based filter landed in 0.3.2 and have never run here.

Compounding it: action/ and action.yml are byte-identical between v0.3.1 and v0.3.2 (git diff 80b18d8 v0.3.2 -- action/ action.yml is empty), so #491 changed nothing that executes. The SHA bump is still correct supply-chain hygiene — it just does not fix this bug.

Fix

cargo update -p soothfast --precise 0.3.2, committing Cargo.lock. 0.3.2 is published and satisfies the existing soothfast = { version = "0.3", features = ["runner"] } dev-dependency, so no manifest change is needed.

Acceptance, unchanged from the original plus one

• After the next bot regeneration, Regenerate soothfast outputs and Regenerate derived artifacts no longer appear under ### 🔧 Internal.
• The ### 📦 Dependencies section still lists its dependabot entries. Their disappearance would mean the filter over-matches and is grounds to revert.
• New: the version the action installs is verifiable from Cargo.lock, not inferred from the action pin.