Cardano Updates

Vote on the hash of the ranking block that announced the EB instead of the
LeiosPoint, which comprises the slot number and EB hash. This forbids reusing
Leios certificates across Praos forks.

With the config parsing now handled by cardano-config and synthesize
taking a ready-made ProtocolInfo, db-synthesizer no longer needs the
vendored node/api machinery in-repo. Remove it entirely:

- 'initialize' and its adapters (the genesis/credential reading and
  protocol assembly) leave; they belong downstream, built on cardano-api.
- Delete the vendored Cardano.Api.*, Cardano.Node.Protocol.* and
  Cardano.Node.Types modules (no remaining consumers), and prune the
  now-unused build-depends (base16-bytestring, cardano-crypto,
  transformers-except).
- Trim DBSynthesizer.Types to the node/api-free option types.

The tools-test integration test becomes synthesis-only: it builds a
forging-capable protocol via the testlib (new
mkSimpleTestProtocolInfoForging, which also returns the block forgers and
genesis) instead of a node configuration file, and forges within the
testlib's KES validity window. The config-driven
synthesise -> immutalise -> analyse pipeline (and the executable) move
downstream. Drop the now-unused config fixtures.

All tool executables, cardano-test and tools-test still build and pass.

Reshape 'synthesize' to accept the (ProtocolInfo, block-forgers) pair
produced by 'protocolInfoCardano', plus the forge options, epoch size and
ChainDB directory directly. Constructing the protocol from a node
configuration is now the caller's responsibility, so 'synthesize' no
longer touches CardanoProtocolParams or the configuration filesystem.

Also remove the standalone db-synthesizer executable (app + CLI parser +
cabal stanza); it will be provided downstream. The tools-test integration
test now builds the protocol itself (initialize + protocolInfoCardano)
and still exercises the full synthesise -> immutalise -> analyse pipeline.

No behavioural change; tools-test still passes.

Replace db-synthesizer's locally-implemented config parser with the
shared cardano-config package. 'initialize' now parses the node config
with cardano-config and adapts it into the Node*ProtocolConfiguration
records that mkConsensusProtocolCardano consumes: byron-era settings,
genesis file paths (including Dijkstra via the testing config's
experimental genesis) and the hard-fork triggers.

Removes the local parser entirely: the NodeConfigStub type, the
FromJSON/AdjustFilePaths orphan instances (Orphans.hs) and the
confConfigStub field. Forging credentials still come from the tool's own
CLI NodeCredentials; the byron software version is hard-coded, mirroring
the node, since cardano-config does not model it.

tools-test still passes (synthesise -> immutalise -> analyse).

Replace db-analyser's locally-implemented CardanoConfig JSON parser with
the shared cardano-config package. The genesis file paths, byron network
magic, genesis hashes and hard-fork triggers are now read from
cardano-config's NodeConfigurationFromFile, with small boundary
conversions for the hash/network-magic representations. db-immutaliser
reuses this path via CardanoBlockArgs, so it migrates too.

No behavioural change: the tools-test integration test (synthesise ->
immutalise -> analyse) still passes with matching block counts.

Wire the shared cardano-config package into the build so the tools can
migrate off their locally-implemented config parsers. The local path is
a development pin and must become a source-repository-package / CHaP
release before this lands.

- Import `Amount` as a type-only import (used only as a type).
- Type `reference_script_hash` as non-null: the query inner-joins `script`
  and filters on its hash, so the column is always present.
- Simplify the `amount` array construction using the `...(row.amount ?? [])`
  pattern already used by /accounts/:stake_address/utxos.

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

On a heavily-churned APFS build volume, reading a freshly-written file can
return a stale recycled-block page instead of the bytes just written, so a
build step that copies the file lands corrupted bytes in $out.

This first showed up as invalid aarch64-darwin code signatures: ld64 builds
the executable in an in-memory buffer, hashes it for its ad-hoc signature,
then write()s that buffer to disk (it avoids mmap, rdar://66598213) -- so the
linked binary is valid, but the later install copy read a stale page and the
binary in $out no longer matched ld64's embedded signature, so macOS SIGKILLed
it at startup ("Code Signature Invalid"). The bad signature was only the
symptom; the same stale read can silently corrupt any copied file, and on
x86_64-darwin (where these ad-hoc signatures aren't enforced) it would go
unnoticed. Cabal's own copyFile is no safer than cp -- both copy via cached
read()/write() -- so the fix can't live in either copier alone.

Fix it at the source rather than re-signing: before each copy, flush the
freshly-written files to stable storage (F_FULLFSYNC) and drop their stale
page-cache mapping (F_NOCACHE), so the copy reads exactly the bytes that were
written and carries ld64's original signature through unchanged.
builder/darwin-flush.nix provides flushDir / flushFile helpers (no-ops off
darwin, enabled on both darwin arches); they run before the install copies in
the v1 builder (comp-builder.nix) and at both copy points of the v2
cabal-slice path (build-cabal-slice.nix, comp-v2-builder.nix).

Validated on aarch64-darwin with both builders: the cardano-ledger-shelley
test suite builds and runs (168 examples, 0 failures) and the resulting binary
keeps ld64's original adhoc,linker-signed signature (no re-sign).

Add the generator for valid scripts.

Pruning epoch settings before the signer registrations that reference
them broke the foreign key constraint after a large epoch gap.

Reading the verifying keys with an empty constraint system produced a
degenerate key, breaking the certificate hash round trip in the client.

Clamp the signer retrieval epoch to the genesis epoch when computing the
network configuration, so the aggregator can start at epoch 0.

The IVC SNARK aggregation now produces the AncillaryVerifierData so
certificates carry it and the embedded IVC proof can be verified.