Cardano Updates

From https://github.com/IntersectMBO/cardano-node at 97036a66bcf8c89f687ae57a048eecc0389977ef

After all sub-rule transitions (`SUBLEDGERS`, `CERTS`, `GOVS`, `UTXOW`),
apply batch-wide direct deposits to the final CertState via
`applyDirectDeposits` and `allDirectDeposits`.

`Ledger.lagda.md`:
+  Update `LEDGER-V` output: compute `certStateFinal` by applying
   `allDirectDeposits` to `certState₂`, use `certStateFinal` in the
   output `LedgerState` and in `rmOrphanDRepVotes`;
+  `LEDGER-I` unchanged (invalid batches don't apply deposits);
+  Document direct deposit application ordering and phantom asset
   prevention rationale.

`Ledger/Properties/Computational.lagda.md`:
+  Update `computeProof` valid branch to compute `certStateFinal` and use
   it in the output `LedgerState`.
+  Clean up redundant code.

`applyDirectDeposits` uses `∪⁺` (union-with-addition) on the `rewards`
map, so a credential not present in `RewardsOf certState₂` is added as a
new entry rather than rejected.  The pre-existing SUBUTXO/UTXO premise
`dom (DirectDepositsOf tx) ⊆ dom (AccountBalancesOf Γ)` only checks
against the pre-batch balances `RewardsOf certState₀`, so it does not
catch the case where a credential is registered pre-batch, deregistered
during `CERTS`, and direct-deposited to in the same batch.  Without the
new premise, the resulting `certStateFinal` is internally inconsistent:
the credential has a positive `rewards` entry but no corresponding
`voteDelegs`, `stakeDelegs`, or `deposits` entry — effectively re-
registering the credential without a key deposit.

Add the phase-1 premise

    dom (allDirectDeposits tx) ⊆ dom (RewardsOf certState₂)

to `LEDGER-V` to rule this out.  Filtering `allDirectDeposits tx` by
`dom (RewardsOf certState₂)` would be an alternative, but it would
silently destroy user funds when a deposit and a deregistration race in
the same batch.  The premise is symmetric to (and complements) the
existing pre-batch SUBUTXO/UTXO check.

Update `Ledger/Properties/Computational.lagda.md` for the new premise,
and pass `UTxOStateOf s₁` explicitly to `computeUtxow` in the LEDGER
valid branch (the previous `_` resolved by chained unification through
the LEDGER-V constructor, which was fragile and obscured intent).

TODO: fix `Ledger/Properties/Computational.lagda.md`; it's choking on
the new premise.

Co-authored-by: Copilot <[email protected]>

Bump iohkNix for blst input update

Bump iohkNix for blst input update

Bumps [github.com/blinklabs-io/gouroboros](https://github.com/blinklabs-io/gouroboros) from 0.153.1 to 0.166.1.
- [Release notes](https://github.com/blinklabs-io/gouroboros/releases)
- [Changelog](https://github.com/blinklabs-io/gouroboros/blob/main/RELEASE_NOTES.md)
- [Commits](https://github.com/blinklabs-io/gouroboros/compare/v0.153.1...v0.166.1)

---
updated-dependencies:
- dependency-name: github.com/blinklabs-io/gouroboros
  dependency-version: 0.166.1
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <[email protected]>

#2501 placed the shared patch at `builder/cabal-install-patches/`
and referenced it from `nix-tools/cabal-install-patches.nix` as
`../builder/cabal-install-patches/...`.  That breaks the static
nix-tools build (e.g. job
`aarch64-darwin.nix-tools.static.zipped.nix-tools-static-no-ifd`,
build 1046198 on ci.zw3rk.com) with

  error: access to absolute path '/nix/store/builder' is forbidden
         in pure evaluation mode (use '--impure' to override)

`cabalProject'` copies `src = ./.` (the nix-tools dir) to the
nix store and re-evaluates module paths from there.  A path that
escapes the source tree resolves to `/nix/store/<...>/../builder`
→ `/nix/store/builder`, which doesn't exist and is rejected
under pure-eval.

Move the patch into `nix-tools/cabal-install-patches/` so the
relative path (`./cabal-install-patches/...`) stays inside the
copied source tree.  Both the regular and static nix-tools
builds still import the same shared module, so they continue to
patch cabal-install identically.

Signed-off-by: Jenita <[email protected]>

Signed-off-by: Jenita <[email protected]>