fix: release workflow failing with "fatal: not in a git directory"

[Marcogn]

Summary

The Release workflow's first real trigger (with RELEASE_PUSH_TOKEN configured) failed at the "Commit and push version bump" step with fatal: not in a git directory — looked auth-related but wasn't. Pulled the job logs and found two real, unrelated bugs:

1. The actual failure: the container job's actions/checkout step registers the checkout path as a git safe.directory, but that doesn't reliably carry over to later plain run: steps executing inside a job-level container: (this workflow runs inside devkitpro/devkitarm) — they can fail on git operations the checkout step itself just did fine seconds earlier. Fixed with an explicit git config --global --add safe.directory '*' step right after checkout, in the same execution context later steps use.
2. A masked, separate bug: the version-format check used bash's [[ ... =~ ... ]], but this step's shell is POSIX sh (dash) in this container, not bash — [[ doesn't exist there, and since a failing if condition doesn't trigger sh -e, the broken check was silently skipped rather than failing the step. This is exactly what let 2.4 (missing the patch number) through as the actual failed run's input, instead of requiring 2.4.0. Rewritten with grep -Eq, already used elsewhere in this same script, and portable POSIX.

Test plan

• python3 -c "import yaml; yaml.safe_load(...)" — workflow YAML parses cleanly
• Confirmed /bin/sh in this sandbox is dash, same as the failing container — ran the new grep -Eq check directly under real dash: rejects 2.4, v2.4.0, garbage; accepts 2.4.0
• Ran the entire "Validate and apply version bump" script body end to end under sh -e against a mock CHANGELOG.md/source/types.h, confirming the correct ## v2.4.0 (date) heading and VERSION_STRING bump
• Real trigger of the Release workflow (this fix can only be fully confirmed by actually running it — will need to be triggered again after merge)

---

Generated by Claude Code