chore(actions): name every run, and stop re-scanning the merge commit

[eaitbrahim]

1. run-name on all seven workflows

The Actions list titles every run with the commit message, so one push to main produced four entries all reading Merge pull request #673 from CodeGateSoftware/chore-v0.13.2-bump — four different checks that looked like one job running four times.

12:22:08Z  security          ev=push  sha=6ca893a  title=Merge pull request #673 from …
12:22:08Z  Migrate database  ev=push  sha=6ca893a  title=Merge pull request #673 from …
12:22:08Z  CI                ev=push  sha=6ca893a  title=Merge pull request #673 from …
12:22:08Z  Code Quality      ev=push  sha=6ca893a  title=Merge pull request #673 from …

Applied to seven, not the four that collide today — install-smoke and installer-smoke already run on PRs, and a release run under a commit-message title is the same confusion, just rarer.

Deliberately not github.event.head_commit.message. That was the obvious interpolation and it's the wrong one here: this repo writes long multi-paragraph commit messages, GitHub already shows the commit beside every run, and re-titling with it restores exactly the clutter being removed. What the default title drops is the workflow's identity, so that's what run-name carries — name, event, ref:

CI · push · main
Security audit · pull_request · chore-actions-runname

2. security.yml no longer runs on push

Both its jobs ran a second time on the merge commit to re-answer what the PR run answered four minutes earlier. dependencies audits uv.lock, which the merge doesn't change, and neither job reads anything a merge could combine differently.

Measured over the last 40 runs: 11.4 minutes, ~2.5 per merge (30s dependencies, ~2min codeql).

ci.yml keeps its push trigger. When two PRs merge in quick succession the post-merge run is the only thing that ever tests the tree that actually landed — and that argument doesn't transfer to a dependency audit.

⚠️ The tradeoff, which your rationale didn't cover

Code scanning reports alerts against the default branch, and that baseline is refreshed by analyses of the default branch — which now means the weekly cron alone. A finding introduced by a merge, or an alert a merge fixes, can take up to seven days to appear or clear in the Security tab.

PR analysis is unaffected and still runs on every change, so nothing reaches main unscanned; what's slower is the summary of what's on main, not the scanning. It's recorded in the file with the note that if the lag ever matters, restore push rather than shortening the cron — a daily scan pays most of the cost for a fraction of the freshness.

Happy to revert this half alone if you'd rather keep same-day Security-tab accuracy; the run-name half stands on its own.

Verification

New pin discovers every *.yml from disk rather than listing them, so a workflow added tomorrow is covered on the day it lands. 4 mutants, 4 killed — including one asserting the commit-message interpolation is rejected. Full suite 5110 passed / 3 skipped; ruff clean.