Cardano Updates

amaru-relay-1/2 peered directly with producers p1/p2. Point them at relay1/relay2
instead: these relays are in the fault-exclusion set, so the system-under-test
syncs from a stable upstream while only the amaru relays take faults. Add a
depends_on so each amaru waits for its relay to start.

epoch_length=256 kept the stability window inside an epoch but pushed the
2-epochs-behind-immutable bootstrap to ~slot 900 (~15 min), past the Antithesis
setup-time budget, so runs aborted incomplete before amaru ever started.

k=5, f=0.2 gives windows 75 (3k/f) and 100 (4k/f), both < epoch_length=120, so
rewards still stabilise in-epoch, and the bootstrap reaches its 2-epochs-behind
point by ~slot 360 (~6 min). Applied consistently across testnet.yaml,
amaru-runtime/global-parameters.json and amaru-runtime/era-history.json.

moog v0.5.x renamed the linux tarball from moog-*-linux64.tar.gz to
moog-<ver>-x86_64-linux-musl.tar.gz, so the download glob matched nothing
and 'install moog' failed. Match the versioned musl tarball (excludes
moog-agent). Unblocks every cardano-node.yaml launch.

Tasks: #161

stability_window=3k/f=150 and randomness_stabilization_window=4k/f=200 must
be smaller than the epoch; the previous epoch_length=120 made the rewards
stake snapshot never stabilize in-epoch, so the relay died with
RewardsSummaryNotReady at the first boundary. 256 clears both windows.

The lib-consuming adversary (consumes cardano-node-clients @76ae585) supports
protocol version 12; publish-images rebuilds the image from commit 06c56bd.

Tasks: #161 #165

Pin cardano-node-clients at 76ae585019cd239f3f43dbec55ea4af36b8cd0cd and align the adversary component with the cardano-node 11.0.1 / PV12 dependency line.

This drops the local PV11-only chain-sync adversary duplicate and imports the upstream PV12-capable adversary modules instead.

Tasks: #165

The trace fix unmasked a real finding: 'cluster fork depth < k' failed
(62 reorgs > k). In a 2-producer cluster a network partition is a 1-vs-1
split with no majority, so a fork grows unbounded by k. Fix it properly:
- add p3 -> a partition leaves a 2-vs-1 majority that anchors the
  canonical chain, so only the minority reorgs;
- raise securityParam k=10 -> 50 (epochLength 1000 -> 5000, preserving
  cardonnay's 10k/f nonce-stability ratio) so the minority's reorg over a
  multi-minute split stays < k.
Epochs become ~16.7 min, so governance runs need the 3h duration; bump
first_setup's epoch-wait to 1800s. Validated locally: cardonnay
generates a valid 3-pool genesis with securityParam 50 / epochLength 5000.

Pin cardano_amaru to the producer image published from amaru-bootstrap main
(lambdasistemi/amaru-bootstrap@fba902da), which bundles amaru
feat/testnet-bootstrap: create-snapshots offline mode + bootstrap migration,
runtime era-history/global-parameters, testnet tvar era-history sidecar fix,
and the short-epoch ledger/consensus fixes.

Remove the created/rejected two-log coordination; the python vote driver
now selects live InfoActions from gov-state (live_info_actions) via
clusterlib, never retires (vote_transient_failure on transient failure),
and create just submits. Stateless, self-healing — matches bash.

A live Antithesis run showed the two-log coordination (created.log /
rejected.log, created - rejected difference) over-retiring: under a
block-production stall, transient faucet-lock/submit failures were
misclassified as rejections and permanently dropped still-valid actions
(~50 retirements, only 1 a real VotingOnExpiredGovAction).

Remove the local ledger entirely. The vote driver now reads the live
InfoAction set straight from the node via an N2C gov-state query
(live_info_actions); relay1 is fault-excluded and a LocalStateQuery
answers even during a stall. An action leaves the set only when the
ledger expires/enacts it, so a transient failure is self-healing — the
action is picked again next tick (vote_transient_failure coverage,
no retire). create no longer publishes anything; the drivers are
stateless and the chain holds all the state.

Replaces action_lifecycle_closed (poisoned by the bug) with a stateless
action_near_expiry derived from gov-state's expiresAfter, and adds
actions_live. Validated locally: votes accumulate to full quorum via
gov-state selection, no created/rejected logs created.

The nightly scheduled run has failed at 'Install moog' every cron tick
since moog 0.5.x dropped the moog-*-linux64.tar.gz asset (last green
2026-06-01). Replace the get-latest-release + release-downloader actions
with a gh release download that picks the statically-linked
moog-*-x86_64-linux-musl.tar.gz, filtering out the agent/oracle tarballs.

Also add an 'Alert on scheduled failure' step (issues:write) that opens
or appends to a single tracking issue, so a silently-failing nightly run
becomes visible instead of rotting for days.

The nightly scheduled run has failed at 'Install moog' every cron tick
since moog 0.5.x dropped the moog-*-linux64.tar.gz asset (last green
2026-06-01). Replace the get-latest-release + release-downloader actions
with a gh release download that picks the statically-linked
moog-*-x86_64-linux-musl.tar.gz, filtering out the agent/oracle tarballs.

Also add an 'Alert on scheduled failure' step (issues:write) that opens
or appends to a single tracking issue, so a silently-failing nightly run
becomes visible instead of rotting for days.