ci(release): pass tag message via env to prevent shell injection (fix empty v2.6.0-testnet)

[mateeullahmalik]

Summary

The release pipeline on tag pushes has been broken since (at least) v2.6.0-rc1, and again on v2.6.0-testnet. Both releases were published to GitHub with zero downloadable assets, which means sn-manager on the testnet fleet cannot fetch the update tarball — the testnet SNs are stuck on v2.5.0-testnet.

Root cause

In .github/workflows/build&release.yml, the Check deploy intent step did:

- name: Check deploy intent
  id: deploy_check
  run: |
    TAG_MSG="${{ steps.tag_info.outputs.tag_message }}"
    if echo "$TAG_MSG" | grep -qi '\[no-deploy\]'; then
      ...

${{ steps.tag_info.outputs.tag_message }} is expanded by the workflow engine before the shell sees it, so the tag/commit body is spliced verbatim into the bash script. For the v2.6.0-testnet tag, the merge-commit body included lines like Verified via deadcode diff on origin/master ... — bash then tried to execute the token deadcode and aborted with exit 127. Everything after Check deploy intent (including the artifact upload step) was skipped, so the release stayed empty.

Failing run: https://github.com/LumeraProtocol/supernode/actions/runs/28608759515

Log excerpt:

line 22: deadcode: command not found
##[error]Process completed with exit code 127.

Fix

Pass the tag message via the step's env: map instead of ${{ }} interpolation. This is the GHA-recommended pattern for consuming multi-line and/or untrusted values inside run: scripts. Behavior is otherwise unchanged (still a single case-insensitive grep for [no-deploy], still writes draft=… to $GITHUB_OUTPUT).

Why not just re-run the failing job?

Because the workflow runs on every tag push and the failure is deterministic for any tag whose message happens to contain a token that shells look up as a command. Same bug would take down every future testnet/mainnet release cut from a merge commit with a rich message.

Blast radius

• Affects only .github/workflows/build&release.yml, only the release job, only the Check deploy intent step.
• No change to the actual build, artifact naming, tarball layout, softprops/action-gh-release step, or release-body composition.
• Prepare Release Body (line 208) also references ${{ steps.tag_info.outputs.tag_message }} but does so inside a quoted heredoc (<<'EOT') which suppresses expansion, so it is not vulnerable to the same failure mode and is intentionally left untouched to keep the diff minimal.

Rollback

Revert the commit; there's no state or migration involved.

Post-merge action

Once this lands on master, I will:

1. Cherry-pick nothing — the existing v2.6.0-testnet tag already contains all the intended code; only the release assets are missing.
2. Attach the correctly-built supernode-linux-amd64 + supernode-linux-amd64.tar.gz to the existing v2.6.0-testnet release (built from tag SHA 095b2f2, matching the tag exactly). This is what sn-manager needs.
3. Verify testnet fleet rolls forward via ./testnet_version_check.sh.

Verification of this PR

• python3 -c "import yaml; yaml.safe_load(open('.github/workflows/build&release.yml'))" → OK.
• Diff is 14 lines, no behavior drift.
• The next tag push (after merge) will exercise the fixed step end-to-end.