fix(ci): add rustup target add for workspace-pinned toolchain in binary-release

[noahgift]

Summary

• The dtolnay/rust-toolchain action's targets: parameter installs targets on the action-resolved toolchain, but rust-toolchain.toml pins channel 1.93.0 which overrides it for any cargo invocation in the workspace.
• Native cross-compiles (x86_64-musl) consequently fail with can't find crate for core — the pinned toolchain has no musl target.
• Add an explicit `rustup target add ${{ matrix.target }}` step gated on `!matrix.cross` (the cross targets use the cross Docker image which carries its own toolchain, so they don't hit this).

Why

Same root cause as the fix already merged in paiml/forjar PR #124 and paiml/bashrs PR #200. All paiml workspaces with a pinned rust-toolchain.toml exhibit the same failure mode for native cross-compiles in binary-release.yml.

Evidence

The v0.31.2 backfill ran the unfixed workflow:

• aarch64-unknown-linux-gnu — succeeded (cross image, unaffected)
• aarch64-unknown-linux-musl — succeeded (cross image, unaffected)
• x86_64-unknown-linux-gnu — succeeded (gnu target ships on rust-toolchain.toml's host triple)
• x86_64-unknown-linux-musl — failed with can't find crate for core

Once this PR merges I'll re-trigger the v0.31.2 backfill via gh workflow run "Binary Release" -f tag=v0.31.2 to attach the missing musl tarball.

Test plan

• Edit adds the step in the same place as the bashrs PR (between the dtolnay action and Install musl tools)
• Step is gated on !matrix.cross so it only runs for native targets
• CI: binary-release workflow on this PR completes (workflow runs on release: published and workflow_dispatch only, so PR CI doesn't exercise it directly — verification happens at the next backfill)

🤖 Generated with Claude Code