Cardano Updates

fix(persistence): avoid hitting SQLite limits when doing blocks and transactions bulk storage

This property test checks:
1. Targets match specified values when target baseline changes in
Genesis mode
2. Targets = nullPeerSelectionTargets in safe mode
3. Targets reach design values when churning

* mithril-persistence from `0.2.64` to `0.2.65`

This reverts commit 6bed07fda4ee27e6df4245b1065368f5a5e9dc9d.

There's still more works to do for this refactor to take fruit:

We needs to be able to provide part of the sql query after
`Query::get_definition` as we only know after this call the number of
rows to binds when doing insert or update.

Support ghc-9.14 and bump dependencies.

The `expectedUTxO` unconditionally included `utxoToCommit`, but when
`snapshotVersion == v` (no `Increment` was posted), the fanout correctly
excludes `utxoToCommit`.

We didn't notice the test flaw because it was hidden, because both
`someUTxO` and `someUTxOToCommit` used identical values (2M lovelace),
so `containsOutputs` matched on TxOut content.

This PR aligns `expectedUTxO` with the actual fanout logic. It uses
different lovelace amounts so we will not be tricked by the hidden
mismatch.

<!-- Describe your change here -->

---

<!-- Consider each and tick it off one way or the other -->
* [ ] CHANGELOG updated or not needed
* [ ] Documentation updated or not needed
* [ ] Haddocks updated or not needed
* [ ] No new TODOs introduced or explained herafter

Create 2026-02-09-project-committee-meeting.md

Due to pipelining we use the *Stmt directly

Use a ShortByteString instead of an existential type for block hashes