[IMPROVEMENT]: Add macOS binary to GitHub Releases

[x15sr71]

In raising this pull request, I confirm the following (please check boxes):

Reason for this PR:

• This PR adds new functionality.
• This PR fixes a bug that I have personally experienced or that a real user has reported and for which a sample exists.
• This PR is porting code from C to Rust.

Sanity check:

• I have read and understood the contributors guide.
• I have checked that another pull request for this purpose does not exist.
• If the PR adds new functionality, I've added it to the changelog. If it's just a bug fix, I have NOT added it to the changelog.
• I am NOT adding new C code unless it's to fix an existing, reproducible bug.

Repro instructions:

This PR only changes CI/release automation and does not modify CCExtractor’s runtime behaviour.

---

Summary

This PR updates the macOS CI workflow so that the existing build_mac.yml job not only builds and uploads a CI artifact, but also attaches the macOS binary to GitHub Releases when a release is published. Today the main way to install CCExtractor on macOS is via Homebrew, or by building from source, and there is no official macOS binary on the Releases page.

GitHub Releases currently include Windows installers/portable zips and multiple Linux artifacts, but no macOS binary, even though the mac workflow already builds ./mac/ccextractor and uploads it as a workflow artifact. This PR closes that gap.

What this PR changes

• Adds a release: types: [published] trigger to build_mac.yml so the macOS workflow also runs when a release is published.
• Adds a Get version step and a release upload step to the build_shell job that, on release events, names the binary ccextractor-<version>-macos and attaches it to the GitHub Release using the same softprops/action-gh-release pattern as the AppImage and .deb workflows. On non-release runs the version falls back to reading from src/lib_ccx/lib_ccx.h.

Behaviour / user impact

On pushes and pull requests:
Behaviour is unchanged. The macOS workflow continues to build and upload a CI artifact named CCExtractor mac build. The new upload step is skipped.

On release events (types: [published]):
The existing build_shell job builds ./mac/ccextractor, copies it into ./mac/artifacts, and uploads it as a workflow artifact (as today). The new step then attaches ./mac/artifacts/ccextractor-<version>-macos (for example ccextractor-0.96.6-macos) to the GitHub Release that triggered the workflow.

As a result, future GitHub Releases will also include a downloadable macOS binary alongside the existing Windows and Linux artifacts, instead of macOS users having to fetch a transient CI artifact or build from source.

Testing

• Downloaded the CCExtractor mac build artifact from a successful "Build CCExtractor on Mac" workflow run.
• Extracted the artifact locally and ran ./ccextractor --version on macOS.
• Confirmed that Gatekeeper shows the standard "cannot verify" warning for unsigned binaries, and that after allowing it via "Open" / Privacy & Security, ./ccextractor --version runs successfully.

This demonstrates that build_mac.yml already produces a working ./mac/ccextractor binary at the expected path; this PR only wires that existing binary into GitHub Releases. On a push run, the CI artifact is also renamed to ccextractor-<version>-macos using sed to parse the version from src/lib_ccx/lib_ccx.h; grep -oP is not used, as it is Linux‑only and would silently fail on macOS runners.

On the CI side, the new upload step reuses the same condition and action-gh-release configuration as the existing Linux packaging workflows, just pointing at the macOS artifact, so the behaviour is consistent with what already runs for AppImage and .deb.

Notes / limitations

The macOS binary uploaded by this workflow is not signed or notarized, so macOS will show the usual Gatekeeper warning for binaries from an unidentified developer on first run. Users can still run it via the standard “Right‑click → Open → Open” flow and then allow it under System Settings → Privacy & Security → Allow Anyway.

This PR intentionally does not attempt to introduce code signing or notarization; that would require an Apple Developer ID and a separate design discussion.

• This PR only adjusts release automation and does not change CCExtractor's runtime behaviour, so no changelog entry is added.