fix(ci): quote release tags in generated github workflows

[jpreagan]

Summary

This hardens generated GitHub release workflows by passing release tags as data instead of shell command fragments.

Previously the generated workflow built --tag=... fragments from GitHub tag inputs/refs and interpolated them into run: shell scripts. This PR changes those paths to use environment variables plus quoted bash argv arrays before invoking dist.

It also scopes the default workflow permission from root-level contents: write to root-level contents: read, with write permissions added only to publishing jobs that need them.

I tried to report this through the private contact path first, but the listed email address bounced.

Validation

• cargo check -p cargo-dist
• cargo fmt
• cargo test -p cargo-dist tag --lib
• cargo test -p cargo-dist --test integration-tests -- --test-threads=1
• cargo clippy --all-targets -- -D warnings
• git diff --check

I also generated a downstream workflow from this branch and confirmed the unsafe tag interpolation patterns were gone.

[mistydemeo]

I tried to report this through the private contact path first, but the listed email address bounced.

I missed that the contact email still references the axo.dev domain; I'll get that fixed. Thanks for flagging this.

[mistydemeo]

We've reviewed this and concluded that we don't believe this is a security issue. Creating a git tag is already a privileged operation; someone with the ability to create a tag in a repo doesn't need to abuse shell injection in order to do something.

Regarding the change to contents: read, did you test this and confirm that it works with these permissions?

[jpreagan]

Regarding the change to contents: read, did you test this and confirm that it works with these permissions?

Tested and works. That said, I'm happy to split the least privilege permissions change out if you'd prefer this PR stay focused only on the tag handling.

[jpreagan]

We've reviewed this and concluded that we don't believe this is a security issue. Creating a git tag is already a privileged operation; someone with the ability to create a tag in a repo doesn't need to abuse shell injection in order to do something.

Will respect whatever classification you folks land on here. My thinking is that in a compromised token or supply chain scenario, an attacker may get enough access to push a tag without being able to modify protected branches or reviewed workflow code. The generated workflow should ideally preserve that boundary by passing the tag as data to dist, rather than letting the shell parse it as syntax.