fix(ci): prevent tag injection in release workflow

[micahkendall]

Motivation

• The release workflow interpolated github.ref_name directly into shell run blocks which created a command-injection vector when tags contain shell metacharacters.
• The intent is to preserve release behavior while eliminating unquoted tag text from shell command construction so CI secrets cannot be exfiltrated.

Description

• Removed the tag-flag workflow output that preformatted --tag=... with github.ref_name to avoid embedding untrusted text into shell fragments.
• Pass the raw tag through a safe environment variable TAG in the plan step and propagate TAG into downstream job env contexts.
• Rewrote plan, local/global build and host run blocks to call dist with either --tag "$TAG" (quoted) or no --tag when empty, and to branch on the event type without building shell snippets from the tag.
• Kept existing behavior (dist plan/host logic and conditional publishing) while eliminating direct interpolation of github.ref_name into run script text.

Testing

• Ran a repository search for remaining unsafe patterns with rg -n "tag-flag|github.ref_name" .github/workflows/release.yml and verified no direct interpolation remains in run blocks.
• Visually inspected all dist invocations in .github/workflows/release.yml to confirm they now use the TAG env var and quoted --tag "$TAG" or omit the flag when empty.
• Attempted a YAML parse using Python (yaml.safe_load) but the environment lacked PyYAML, so that automated parse check could not be completed in this environment.

---

Codex Task

[SupernaviX]

This is not useful. This release pipeline is generated by cargo dist. The build is failing because the generated code has changed. We can allow drift, but that's a bad idea without a compelling reason (i.e. something we need that dist doesn't do out-of-the-box).

Someone else opened a PR to cargo-dist to fix this, yesterday. Meanwhile, this isn't a huge threat, because the only people who can exploit it are people with push access.