CI: fix remaining zizmor template-injection findings

[brtnfld]

Summary

Fixes the 22 remaining open zizmor template-injection alerts in the Security tab, all in four VOL workflow files:

• vol_log.yml (8 findings)
• vol_rest.yml (7 findings)
• vol_ext_passthru.yml (4 findings)
• vol_cache.yml (3 findings)

Changes per file: move ${{ inputs.build_mode }} and ${{ runner.workspace }} out of run: scripts into step-level env: blocks; replace ${{ github.workspace }} with the built-in $GITHUB_WORKSPACE env var directly.

Once this and #6447 merge, the Security tab will be clean — any future zizmor finding will be a real signal rather than pre-existing noise.

[github-actions]

Review Checklist

This PR touches the following areas. Each needs at least one
sign-off from its listed owners before merging — an approval
covering only one area does not satisfy the others.

• .github — @hyoklee

[jhendersonHDF]

All of these are passed in from vol.yml and can't be injected, these are just false positives. $RUNNER_WORKSPACE and ${{ runner.workspace }} are also the same and $RUNNER_WORKSPACE already exists, similar to $GITHUB_WORKSPACE and ${{ github.workspace }} so no reason to change those or add environment variables.

[brtnfld]

The issue is to eliminate false-positive noise, so that if a real issue appears later, developers are not already trained to dismiss it. I can have zizmore only scan files that can be directly triggered by external users

[brtnfld]

Closing in favor of the approach in #6447. The VOL workflow files (vol_log, vol_rest, vol_ext_passthru, vol_cache) only have workflow_call triggers — they can never be triggered directly by external users, so template-injection findings against inputs.* in those files are false positives. Rather than making unnecessary code changes, #6447 now narrows the zizmor scan to only user-facing workflows, keeping Security tab alerts meaningful.