Cardano Updates

Bump cardano-node-clients to a37cbd6 which provides:
- balanceFeeLoop (conservation-aware fee convergence)
- computeScriptIntegrity (parameterized by Language)
- spendingIndex
- placeholderExUnits

Remove local ConservationBalance.hs and inline definitions.

balanceFeeLoop finds the fee fixed point for transactions where output
values depend on the fee (conservation equation). Unlike balanceTx, it
does not add inputs or change outputs — the caller provides a function
Coin -> outputs that recomputes outputs for each candidate fee.

Two-phase approach:
1. Evaluate scripts with a fee overestimate to get real ExUnits
2. Patch ExUnits, then run the fee loop with real redeemer sizes

Eliminates the hardcoded 600K fee overestimate. The fee converges
exactly in 2-3 rounds, with excess going to treasury.

Also extracts buildConservationTx to deduplicate ~200 lines between
buildModifyTx and buildRejectTx.

balanceFeeLoop finds the fee fixed point for transactions where output
values depend on the fee (conservation equation). Unlike balanceTx, it
does not add inputs or change outputs — the caller provides a function
Coin -> outputs that recomputes outputs for each candidate fee.

Two-phase approach:
1. Evaluate scripts with a fee overestimate to get real ExUnits
2. Patch ExUnits, then run the fee loop with real redeemer sizes

Eliminates the hardcoded 600K fee overestimate. The fee converges
exactly in 2-3 rounds, with excess going to treasury.

Also extracts buildConservationTx to deduplicate ~200 lines between
buildModifyTx and buildRejectTx.

Extend `Test.Cardano.Ledger.Babbage.TxInfoSpec` with a property test for
Babbage TxInfo translation across PlutusV1/V2/V3/V4:
* correctly translate tx with babbage-era features

Validation checks that the current protocol version is within the era's bounds

The tx_backlog_max_size limit was incorrectly gating locally-generated
transactions based on total backlog depth (including peer-received txs).
Split the single backlog queue into two separate VecDeques so the limit
only applies to locally-generated transactions. Track and report max
backlog watermarks independently for each queue.

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

Agglomerative clustering (Kruskal-style): sorts edges by latency and
merges lowest-latency pairs first, maximizing the CMB lookahead.
Balance controlled by shard-max-size-pct config (default 200%).

Achieves 7-10ms min cross-shard latency vs 1ms for other strategies,
but worse cluster shapes increase cross-shard traffic. For uniformly
connected topologies, zero-latency-clusters (balanced, 1ms lookahead)
still wins on wall clock. Min-latency-clusters would shine on
topologies with natural geographic clusters.

Also adds CMB lookahead to shard startup log for diagnostics.

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

- Add Geographic variant to ShardStrategy, configurable via shard-strategy
- K-means++ clustering on node coordinates, keeping 0-latency components
  together, falls back to zero-latency-clusters if coordinates missing
- Add location field to NodeConfiguration (from topology coordinates)
- Extract union-find helpers to shared module
- Refactor zero_latency_clusters to expose reusable component-building
  and balanced-assignment functions

Benchmarks show geographic helps when topology has clear regional clusters
with high inter-region latency. For uniformly-connected topologies, the
balance penalty outweighs the marginal lookahead improvement.

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

Min-cut uses recursive bisection with Kernighan-Lin refinement to
minimize cross-shard edge count. Also logs cross-shard edge count
and CMB lookahead at startup for diagnostics.

Shard strategy benchmark summary (6 shards, 100 slots, realistic.yaml):
| Strategy              | Wall   | User  | Cross-shard | Lookahead | Sizes              |
|-----------------------|--------|-------|-------------|-----------|--------------------|
| (none, 1 shard)       | 9m19s  | 36m   | —           | —         | [3000]             |
| zero-latency-clusters | 3m48s  | 39m   | 82.0%       | 1ms       | [500x6]            |
| min-latency-clusters  | 4m51s  | 43m   | 55.9%       | 8ms       | [600,600,600,600,300,300] |
| geographic            | 4m18s  | 43m   | 61.9%       | 1ms       | [796,743,703,758]  |
| min-cut               | 4m45s  | 43m   | 80.5%       | 1ms       | [750,750,375x4]    |

For uniformly connected topologies, balance dominates — zero-latency-
clusters wins despite 82% cross-shard edges. Strategies optimizing for
fewer cross-shard edges or higher lookahead create imbalance that
negates their gains. Would benefit from topologies with natural clusters.

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

- Extract actor-model simulation (NodeListWrapper, ActorSimulation,
  init_nodes, run logic) into sim/actor.rs
- sim.rs is now a thin dispatch layer: Simulation newtype wrapping
  SimulationInner enum (Actor vs Sequential)
- Unify sequential single-shard and multi-shard builders into a
  single build_typed() function
- Group cross-shard state into CrossShardState sub-struct
- build() takes event_sender directly, creates its own infrastructure
- Remove dead code (per_shard_node_configs, init_node_impls)
- Net -407 lines across sim.rs + sequential.rs

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

Each shard (ClockCoordinator + NetworkCoordinator + TxProducer) now runs as
its own tokio::spawn'd task, enabling true parallel execution across cores.

Key changes:
- Replace select_all with tokio::spawn per shard (Simulation::run takes self)
- Cross-shard messages route directly NC-to-NC via delivery channels
- Target NC handles timing locally via its own Connection (no broker)
- CMB ceiling: min(peer.time + min_latency) with null message advancement
- Notified::enable() prevents missed notifications across concurrent tasks
- TX generation rate scaled by shard_count for consistent output
- Delete broker.rs (replaced by direct NC-to-NC routing)

4-shard runs ~2x faster than 1-shard with matching simulation results.

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

Rename `sequential-engine: true/false` to `engine: sequential | actor` with
actor as the default to avoid surprises. Add parameters/turbo.yaml convenience
preset (sequential engine, 6 shards, zero-latency-clusters) for ~5x speedup.
Update CLAUDE.md and README.md with engine and shard documentation.

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

Extract the hardcoded PARALLEL_THRESHOLD constant into a configurable
parallel-threshold parameter (default 10, was 32). Add engine and
parallel-threshold to config.schema.json. Disable rayon in the
determinism test since event channel ordering is non-deterministic
under parallel execution.

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

Deduplicate code between actor (driver.rs) and sequential engines:
- Extract NodeEvent, CpuTaskWrapper, schedule_cpu_task, complete_cpu_subtask
  into new common.rs shared module
- Extract TxGeneratorCore from both TransactionProducer (actor) and
  TxGenerator (sequential) into tx.rs; delete TxGenerator entirely
- TransactionProducer now wraps TxGeneratorCore as a thin async actor
- WeightedLookup made pub(super) for reuse

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

Track the maximum tx backlog length (overflow queue behind the mempool)
via events, and add a leios-tx-backlog-max-size config parameter that
applies backpressure on the tx generator when the backlog is full.
Peer transactions are unaffected by the cap.

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

The peer backlog queue was unbounded and could cause memory explosion.
Add leios-tx-peer-backlog-max-size config (null = unbounded) to cap it
independently. Rename the existing backlog config from
leios-tx-backlog-max-size to leios-tx-generated-backlog-max-size for
clarity. Peer txs dropped due to a full backlog are tracked separately
as PeerBacklogFull.

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

Replace the actor-based simulation with a synchronous event loop for
single-shard runs. The sequential engine eliminates tokio coordination
overhead (channels, oneshot allocs, task scheduling) by processing
events directly from a global priority queue.

Events at the same timestamp are batched and processed in parallel
across nodes using rayon, following a Bulk Synchronous Parallel model:
pop batch → resolve deliveries → parallel node compute → apply results.

Enabled by default for single-shard (sequential-engine: true in config).
Falls back to sequential processing for small batches (<32 events).
The actor engine remains available via sequential-engine: false.

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