Allow matlab-actions/run-tests v3.1.1

[kevingurney]

To address: #49962, we would like to allow v3.1.1 of the matlab-actions/run-tests action.

Note: v3.1.1 is not a Prerelease, so we don't expect to run into the "commit churn" which was addressed by #735 for this version. On behalf of the MathWorks CI Team - our sincere apologies for the inconvenience this issue caused.

Note: It is unclear what is preventing matlab-actions/run-tests from eventually ending up in the same state again if a future upgrade is also a Prerelease. Does some kind of additional logic need to be added to the infrastructure to "ignore" prereleases for Dependabot upgrades?

[potiuk]

Hi @kevingurney — thanks for the bump.

Running our automated allowlist check (verify-action-build) on v3.1.1 turns up one issue we'd want to resolve before approving:

✗ dist/bin/win64/run-matlab-command.exe: no SLSA attestation and release v3.1.1 has no SHA256SUMS

The JS rebuild matches cleanly (✓), no curl-downloads, lock file present. The blocker is just the four dist/bin/*/run-matlab-command* launchers that v3.1.x now commits to the tree — they're opaque to any rebuild check, and matlab-actions/run-tests releases don't ship SHA256SUMS or SLSA attestations, so there's no way for us to tie the bytes back to the source/workflow that produced them.

(Side note: vendoring the binaries into dist/ is actually a security improvement over fetching them via common-utils at install time — the SHA-pin now freezes the bytes. We just need the upstream provenance hook to close the verification loop.)

I've opened matlab-actions/run-tests#94 proposing actions/attest-build-provenance (or SHA256SUMS as a release asset) as the fix — same one-line pattern that runs-on/action#37 used. Since you're at MathWorks, you may have a faster path to that team than a drive-by issue does — if you could support the upstream request as a downstream consumer, that'd unblock this PR (and every future matlab-actions/* bump).

Holding approval until upstream provenance lands.