Yes but SHA1 collisions are easy enough to engineer, so even then compromise is probably possible.
(I don't know how hard it is to push a different object to an existing SHA on GitHub—I'm guessing that you probably have to remove all references to the original object at that SHA?)
SHA1 collisions are easy, but nobody has publicly revealed a second-preimage attack. With a collision you create two inputs that hash to the same output, with a second-preimage attack you are given one existing input & have to find a second input that hashes to the same output. Collisions are much easier since you can control both inputs.
That's a good point. Setting up a benign release first that you have engineered a same-hash malicious release you can swap in later is a higher bar than gaining control of a repo and immediately replacing a popular release.
On its own, immutability isn't a complete solution to supply chain attacks. Software still needs to be updated and those updates could contain malware too.
You need immutability and something like sandboxing where actions cannot e.g. dump the memory of the runner process to steal secrets.
The alternative is vetting every single line of code in every dependency and every subdependency perfectly for every update, which is not realistic.