ci: Bump trivy-action to v0.36.0 to fix Trivy scans

[codyfinegan]

Description

Fixes #400.

The Trivy repo and image scans have failed since late April 2026. trivy-action v0.33.1 installs Trivy v0.65.0 by default, and that release no longer exists on GitHub (releases v0.27 to v0.69.1 were removed). setup-trivy fails to download the binary, the scan step exits 1, and the SARIF upload then fails with Path does not exist.

Changes:

• Bump aquasecurity/trivy-action from v0.33.1 to v0.36.0 (pinned to commit ed142fd) in both workflows. v0.36.0 installs Trivy v0.70.0 and setup-trivy v0.2.6.
• Image scan: swap format: template with @/contrib/sarif.tpl for format: 'sarif'. Trivy now warns that the template is deprecated.
• Both scans: set limit-severities-for-sarif: true. Without it, SARIF output ignores severity and uploads every severity. This keeps the Security tab to CRITICAL and HIGH, as the old template did.

Trivy itself is left at the action's default v0.70.0. v0.75.0 is out but is only a week old.

Testing Instructions

1. Check the "Scan repo for vulnerabilities" check on this PR passes.
2. Run the image scan against the branch, e.g. on a fork: gh workflow run scan-images.yml --repo <fork> --ref ci/400-bump-trivy-action
3. Check all 11 image jobs pass, the log shows Trivy v0.70.0, and there is no sarif.tpl is deprecated warning.

Both were run on 313838e: repo scan run 37726376617 and image scan run 37726383764 (on the fork) passed.

After merge, re-check that both workflows are enabled. They were disabled while #400 was open.

Checklist

• Does what the author says it will do
• Testing instructions are provided
• Commit messages make sense and follow the conventional commit standard
• No identified security issues
• No identified maintenance issues
• Any third-party libraries/dependencies use the MIT or Apache 2.0 license
• Changes made are backwards compatible and will not break existing setups
• Changes to scripts in the bin/ directory run correctly on both MacOS and WSL
• Changes to containers can be built locally sucessfully (e.g. via tbuild container && tup container)
• Containers/images are compatible with both AMD64 (Windows) and ARM64 (MacOS)
• Changes made to config.php are compatible with our oldest supported Totara version, our newest Totara version, and Moodle