build-packages template: disable sign-macos-packages for nightly

[dwoz]

Change templates/build-packages.yml.jinja line 38 from hardcoded sign-macos-packages: true to the same per-environment conditional that sign-windows-packages and the others already use:

sign-macos-packages: <% if gh_environment == 'nightly' -%> false
                        <%- else -%> ${{ inputs.sign-macos-packages }}
                        <%- endif %>

Nightly builds no longer submit macOS packages to Apple's notary service. Rationale:

1. Public salt-nightlies today has sign-macos-packages: true in the rendered nightly.yml but the MAC_SIGN_APP_SPEC_PWD / APPLE_TEAM_ID / APPLE_ACCT secrets are empty at runtime, so the notarize step already effectively no-ops there. Setting the flag to false makes the workflow file match the effective behaviour instead of silently hiding it behind empty secrets.

2. Salt-priv (private security fork) inherits the same generated nightly.yml via forward-merge. Its Apple secrets ARE populated, which means the notarize step actually calls Apple's API. Any time those creds go stale (as they did today -- 2023-era app- specific password) the entire macOS build path fails, and by extension the whole nightly pipeline. Turning off signing for nightlies decouples nightly stability from Apple creds rotation.

3. Full releases still sign+notarize -- release.yml has its own path with dedicated sign-* inputs, and the release-context branch of the jinja conditional uses ${{ inputs.sign-macos- packages }} so callers can (and do) opt in.

Regenerated .github/workflows/nightly.yml and staging.yml via the Generate GitHub Workflow Templates pre-commit hook.

• nightly.yml: sign-macos-packages: true -> false (2 call sites)
• staging.yml: sign-macos-packages: true -> ${{ inputs.sign-macos- packages }} (non-nightly branch; staging inputs preserve the prior configurability)