Don't run release workflow if commitlint fails

The GH merge UI allows renaming commits when merging PRs via squash or creating a merge commit. The default commit message for a multi commit PR that is squashed is the title of the PR, which means while the commits in the PR may pass commitlint the squashed commit message may not.

That is generally not an issue for squashes as it doesn't trigger a new semantic release.

For merge commits, however, the default message can often be less than ideal ("Merge #NUMBER from /long/branch-name/without-much-meaning"). If that commit message is changed and doesn't follow the merge commit patterns we can get into a very sticky situation where a new release is created but commitlint has failed. This then leads to a complex cleanup process when trying to amend the commit message, as the old commit has already been tagged so semantic release stops making releases for any new merges to the branch.

Start by locating the GitHub Actions release workflow and the commitlint and semantic-release steps it invokes. Trace how a failed commitlint check currently affects release creation, especially for merge commits. Done means the release workflow does not run when commitlint fails, avoiding a tagged release from an invalid merge commit.