fix: anchor checksum field matching and add sha256sum fallback

[kitsuyui]

Problem

Two issues were found in the checksum verification logic in action.yml:

1. Unanchored grep matching: grep -F " ${target}" performs substring matching without end-of-line anchoring. If upstream ever adds a release artifact whose filename ends with the same suffix as an existing one (e.g. a .sig file), the extracted .sha256 file would contain multiple lines, causing sha256sum --check to fail with a misleading "no such file or directory" error.

2. sha256sum portability: sha256sum is a GNU coreutils command and is not present on bare macOS/BSD. GitHub-hosted runners have Homebrew coreutils installed so this is not normally a problem, but self-hosted runners and local act runs fail with command not found.

Changes

1. Added sha256_verify() helper function immediately after set -euo pipefail. The function prefers sha256sum when available and falls back to shasum -a 256 for BSD/macOS compatibility.

2. Replaced sha256sum --check - with sha256_verify - for the checksums file anchor verification step.

3. Replaced grep -qF " ${target}" with awk -v t="${target}" '$2 == t {found=1} END {exit !found}' for the existence check, performing exact field-2 matching instead of substring matching.

4. Replaced grep -F " ${target}" with awk -v t="${target}" '$2 == t' for the line extraction step, ensuring only lines where field 2 exactly equals the target filename are included.

5. Replaced sha256sum --check with sha256_verify for the archive checksum verification step.

Verification

Tested locally. There is no behavioral change for current gibo releases where all artifact filenames are unique — the awk exact-field match produces the same single-line output as the previous grep for non-conflicting filenames.

Trade-offs

The sha256_verify() helper adds a runtime command -v check per invocation. This is a negligible cost for an install action that runs once per workflow job.