Cardano Updates

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

The branch added a 'Maybe FsPath' export-path field to LSMArgs but did not
update db-analyser's call site. Rather than hardcoding it, surface the LSM
configuration (bloom-filter salt and snapshot export directory) via a new
'mkLSMConfig' method on 'HasProtocolInfo' (default: none). The Cardano instance
reads them from the node config's LedgerDB.LSMSalt and LedgerDB.LSMExportPath
fields, so db-analyser uses the same salt the database was created with (needed
for exported snapshots to be importable) and can export snapshots as it stores
ledger states. Falls back to a random salt when none is configured.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

Built on top of #2060 

# What changed

### 1. From #2060, Percolate the replay goal from `--analyse-from`

`openLedgerDB` previously hard-coded the replay goal to `genesisPoint`.
Because
`initialize` rejects every snapshot whose slot is more recent than the
replay
goal (`InitFailureTooRecent`), a genesis goal rejected *all* snapshots,
so
db-analyser always restarted from genesis and silently ignored
`--analyse-from`.

The replay goal is now derived from the `--analyse-from` argument
(genesis when
it is omitted), so snapshot selection considers the on-disk snapshots
and picks
the newest one that is not more recent than the requested slot.

### 2. Replay up to `--analyse-from` before analysing

With (1), the LedgerDB starts from the newest snapshot at or before
`--analyse-from`, but it was opened with an *empty* stream — no blocks
were
replayed. When no snapshot existed exactly at the requested slot, the
ledger
state (and therefore the analysis) silently began at the older
snapshot's tip
rather than at `--analyse-from`.

`openLedgerDB` is now handed the ImmutableDB and replays blocks on top
of the
chosen snapshot up to the replay goal, so the ledger state is exactly at
`--analyse-from` before the analysis begins. The replay stream stops at
the
first block past the goal, mirroring the `StartFromPoint` behaviour
where the
analyse-from block is the anchor and processing starts after it. When a
snapshot
already sits exactly at the requested slot, the stream stops immediately
and no
blocks are replayed.

If no snapshot exists exactly at the requested slot, db-analyser now
emits a
warning (the replay from an older snapshot up to the goal can be slow),
but
still proceeds.

### 3. Remove the unused `lgrStartSnapshot`

`LedgerDbArgs.lgrStartSnapshot :: Maybe DiskSnapshot` was introduced to
let
db-analyser start from a specific snapshot, but it was only ever set to
`Nothing` and db-analyser never used it. Its purpose is now served by
the
replay-goal-based snapshot selection above, so the field and the
corresponding
`Maybe DiskSnapshot` argument of `initialize` are removed.

**Breaking change** for downstream consumers of `LedgerDB.LedgerDbArgs`.
The
node only constructs `LedgerDbArgs` via `defaultArgs` and never set this
field,
so it is unaffected. A changelog fragment is included.

Carry the prover input into the clerk, return the verifier data alongside the aggregate signature, and accept optional verifier data on verification.

Feed the ancillary proof input into multi-signature creation and persist the returned verifier data on the certificate.