Add binary integration testing support to GitHub Actions workflow

[roger-zhangg]

Changes

• Add a second schedule trigger (4am PST / 12pm UTC daily) that tests against the SAM CLI nightly binary instead of source
• Add workflow_dispatch input install_mode with options: code (default), binary (nightly), latest-release
• Add Makefile targets: init-nightly, init-latest-release, setup-pytest
• Add scripts/install-sam-cli-binary.sh for cross-platform (Linux/macOS) SAM CLI binary installation
• Use gh release download instead of raw curl for GitHub release assets
• Unset SAM_CLI_DEV in binary flows so tests use sam instead of samdev
• Create /usr/local/bin/zig wrapper for SAM CLI's cargo-lambda Rust builds
• Use pytest venv python for setup/reset scripts when available

Testing

Tested via workflow_dispatch with install_mode=binary on the binary-test branch.

[roger-zhangg]

https://github.com/roger-zhangg/aws-sam-cli/actions/runs/22418274086

[valerena]

Just some minor comments, but it looks good

[valerena]

Minor, but you could move this if to outside of the case

[roger-zhangg]

For the first comment, I think it make more sense to actually install sam cli in a venv for normal integ tests. So we get a clearer env and consistency accross the tests. I will make that change

[roger-zhangg]

And yes, the goal is to avoid "making a test wrongly succeed"

[roger-zhangg]

Seems it's not super straightforward to do, the main blocker as "make pr" if we install sam cli in a venv, we need to use that venv to run all the make PR steps and eventually we need to run pytest in the venv as well. It's basically the same as running in system python directly. Unless we create a new workflow "make init-inte-test" but this makes test confusing. Probably better to stick to just make init & install in the system.

[roger-zhangg]

Updated a minor case: our nightly release will not publish, it keeps editing an old release so need to listen on edit event.

[valerena]

The new changes look good!