Good practices for mitigating script injection attacks

The problem I'm trying to solve comes from workflow scanning tools triggering on some patterns used in the workflow file generated by cargo-dist. The workflow file needs to be changed to accommodate those tools (which may have false positives). To avoid breaking CI, the `dist-workspace.toml` file needs to have `allow-dirty = ["ci"]`. But this is not satisfying because the workflow file may drift away.

The solution I'd like would be to change the workflow file generation to follow the [good practices](https://docs.github.com/en/actions/reference/security/secure-use#use-an-intermediate-environment-variable) documented by GitHub when some scanning tool reports something (even when overzealous).

References:
- Here is a commit (without updating tests) that would fix my problem: https://github.com/ia0/cargo-dist/commit/09d8837def3efaa7851d2054ed51b3e7e2e62c0b
- Here is the original PR from the workflow scanning tool that triggered my problem: https://github.com/google/magika/pull/1294/changes#diff-2b580c9156212a6e8960aac74844fdfba9fda0f8a737f7e744082ca95729c50e
- General context about script injection: https://docs.github.com/en/actions/concepts/security/script-injections

Start by reviewing the workflow generation in the repository and comparing the referenced commit 09d8837def3efaa7851d2054ed51b3e7e2e62c0b. Read the GitHub Actions guidance on intermediate environment variables and inspect the generated workflow plus its tests. Done means generation follows the documented mitigation without requiring workflow drift or an untested change.

Written by the indexing model from the issue text.