Update foliage (curl retry backoff + download concurrency limit)

[angerman]

Summary

Updates the foliage flake input to include input-output-hk/foliage#116:

• curl --retry 3 --retry-connrefused — retries transient HTTP errors (408, 429, 500, 502, 503, 504) with exponential backoff (1s, 2s, 4s)
• Download concurrency cap at 20 via Shake Resource — prevents hundreds of simultaneous curl processes from overwhelming GitHub when running with -j 0
• CI actions upgraded — nix-installer-action v9→v21, magic-nix-cache-action v2→v13, cachix-action v14→v16

This addresses the repeated transient HTTP 502 failures seen in #1248 (failed 4 times before succeeding on the 5th manual re-run, each time on a different package).

[neilmayhew]

There are no messages from curl in the logs about http status errors. I don't know whether that's because there were no errors this time, or because curl doesn't output a message if it's able to fetch the URL on a retry.

I couldn't find an accurate way to test this locally, but my impression is that curl will output an error message for each failure even if it succeeds on a subsequent retry, and that means no 502s were encountered on this run.

It may be that the Shake-based rate-limiting mechanism was sufficient to avoid getting the 502s in the first place, though.

This test shows that nothing is fundamentally broken by the changes, so I'm in favour of making the upgrade and seeing how things go. I think we should keep an eye on overall run time for the repo builds and then tweak the Shake resource limit if necessary. When we get the Cabal-file rewriting issue sorted out, and can safely delete the cache, we should try a non-cached run to see how long that takes with this change.

[neilmayhew]

Looking at the run times before and after we re-enabled the cache, I don't think caching provides any improvement. It takes as long to fetch the cache as it does to fetch the tarballs from upstream.

[angerman]

The build-repo failure is the exact HTTP 502 problem this PR fixes — but it occurs in the "Build repository (main)" step, which uses main's foliage (without the retry fix). The PR tip's foliage has the fix but CI never reaches that step.

This is a chicken-and-egg: the CI baseline build always uses main's foliage. Re-running until the transient 502s don't hit. The previous CHaP run (#1249) confirmed the fix works — build-repo passed when using the new foliage.