fix: handle crates with multiple binary targets in release workflow

[JoshuaBatty]

Summary

Fixes the release workflow failing for forc-client because it produces multiple binaries (forc-deploy, forc-run, forc-submit, forc-call) rather than a single forc-client binary.

The workflow now:

• Extracts binary names from [[bin]] sections in Cargo.toml
• Falls back to crate name for crates using src/main.rs
• Iterates over each binary when stripping and packaging

When you release forc-client-0.71.0, it will create:

forc-client-0.71.0-linux_amd64.tar.gz
├── forc-deploy
├── forc-run
├── forc-submit
└── forc-call

Context

• Failing run: https://github.com/FuelLabs/forc/actions/runs/21612021435/job/62282720383
• Previous PR that introduced forc-client: Migrate forc-client from the sway repo #143

Test plan

• Tested binary extraction logic locally for forc-client, forc-crypto, forc-node
• Verify CI passes on this PR
• Test with actual forc-client release

[cursor]

PR Summary

Medium Risk
Changes release artifact stripping/packaging logic in GitHub Actions; mistakes could break publishing or produce incomplete archives across targets, though runtime product code is untouched.

Overview
Fixes the release workflow to support crates that produce multiple binaries by extracting binary names from [[bin]] entries in Cargo.toml and iterating over them for stripping and asset packaging (with a fallback to the crate name when using src/main.rs).

Bumps forc-client to 0.71.1 and updates its changelog to reflect the first release from this repository.

^{Written by Cursor Bugbot for commit 485f81d. This will update automatically on new commits. Configure here.}