Cardano Updates

Mark peras as unsupported. The machinery is interesting though and we
should also make it negotiate leios support like this?

The unit tests are not needed anymore

TODO: Fix cabal.project to not have local paths

On aarch64-darwin, executables built by haskell.nix could ship an invalid
ad-hoc code signature, causing macOS to kill them at startup with SIGKILL
("Code Signature Invalid" / "Invalid Page") before any code runs. It is
intermittent: the same derivation builds a valid binary on one run and an
invalid one on the next, so it slips through CI and lands in the binary cache
(see haskell.nix#2018).

Root cause is a write->sign page-cache coherence race, not an ld64 or sigtool
bug. ld64 ad-hoc signs the executable during linking; for large Mach-Os the
bytes hashed for the signature can differ from what is finally on disk, so the
kernel rejects the signature at load time. The same applies to any signer run
inside the build. macOS `sync` is asynchronous and does not settle it; a real
flush to stable storage (F_FULLFSYNC) does.

Fix: add autoSignDarwinBinariesHook to the component and v2 cabal-slice
builders, with signingUtils patched so sign() F_FULLFSYNCs (+ F_NOCACHE drops
the stale mapping) the binary before reading it for signing. It then hashes
exactly the bytes that land on disk, producing a signature the kernel accepts.

The concrete buildPackages.darwin derivations are overridden directly rather
than via an overlay: `darwin` is a spliced package set, so overlay `//`
additions do not survive splicing, and overrideScope rebuilds far too much.

Verified on cardano-ledger's cardano-ledger-shelley:test:tests (a ~170 MB
binary that reproduced reliably): 6/6 invalid before, 6/6 valid after via the
v1 component builder, and 4/4 valid via the v2 cabal-slice builder
(builderVersion = 2, full 556-derivation tree). Confirmed the hook re-signs
and the binary runs in both.

tasty 1.5.4 causes ~4x higher peak memory under parallel test execution
(510 MiB max residency vs 160 MiB with 1.5.3), causing OOM at GHCRTS=-M900M
on x86_64-linux CI.

Co-Authored-By: Hamish Mackenzie <[email protected]>

Specifically rely on aeson >= 2.3.0.0 to avoid a DoS vulnerability
in earlier versions:

  https://haskell.github.io/security-advisories/advisory/HSEC-2026-0007.html