Cardano Updates

Pulls in:
- adversary:9b439a3 — emits SDK assertions per attack (Reachable
  adversary_chain_sync_started + Sometimes adversary_chain_sync_completed)
- sidecar:9b439a3 — finally_tips_agree.sh emits finally_perturbation_metrics
  with blocks_produced_total and max_slot_lag

Both pins move to the SHA that introduces the perturbation Layer 1
+ Layer 3 changes.

Adds Adversary.SDK with Reachable / Sometimes assertion emitters that
write to \$ANTITHESIS_OUTPUT_DIR/sdk.jsonl (default /tmp/sdk.jsonl).
Wires two assertions into app/Main.hs:

  - reachable("adversary_chain_sync_started", {target_host, point, limit})
    fires once per invocation before connectToNode. Antithesis report
    will show, segmented by target_host, "the adversary fired against
    pN at least once". A host that never gets attacked is visible as
    a missing Reachable hit.

  - sometimes(true|false, "adversary_chain_sync_completed",
              {target_host, tip|reason})
    fires once per invocation on completion. true on clean exit,
    false on connect/protocol failure. Sometimes-true vs Sometimes-
    false buckets quantify how often the adversary actually completed
    a full --limit sync vs being cut short by chaos.

Layer 1 of three for issue #123.

Adds an emit_perturbation_metrics() helper to
components/sidecar/composer/convergence/finally_tips_agree.sh that, on
every run, computes:

  - blocks_produced_total : sum of producers' block heights at end-of-test
  - max_slot_lag          : max(slot) − min(slot) across producers

and emits them as a Sometimes(true) "finally_perturbation_metrics" event
with both numbers in details. The Antithesis report's per-bucket
distribution view then shows the curve across runs without needing a
separate observer.

Slot lag is 0 on a perfectly synchronous cluster, mildly positive
under fault injection, large under attack pressure — gives us a
quantitative comparison for master vs adversary side-by-sides.

Layer 3 of three for issue #123.

Signed-off-by: Chris Gianelloni <[email protected]>

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

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

The two adversary docs described the long-running daemon shape that
was retired in #110. Rewrites both pages to match the current state:

- adversary.md — sleep-forever container, single CLI per tick, single
  driver with --target-host fan-out over all 5 cluster hosts,
  --seed-driven random pick. New CLI flag table. New compose
  fragment. Local test loop via scripts/smoke-test.sh
  cardano_node_adversary. Closing section explains why the daemon
  was retired (two schedulers, targeting bias, lifecycle complexity
  for no benefit).
- adversary-roadmap.md — restructures around CLIs, not endpoints.
  Each future archetype is one binary + one driver, not a new daemon
  endpoint. Tier list preserved; "what's behind us" replaces the
  daemon-era status table. Tickets section reflects the closures
  done in PRs #110 and #122.

Also drops the dead adversary-CI.yaml badge from the top README —
that workflow was retired in 9bc9b23.

The faults-enabled 1h Antithesis run on cardano_node_tx_generator
(commit 12a80b8, session 95887c0ae21ed981bf9e85943bda257f-50-7,
report OOdYZcg__MdS4qqvkORdLTR-) flagged 2 driver-script findings:

  tx-generator/parallel_driver_refill.sh        command_runtime=25.78s
  tx-generator/eventually_population_grew.sh    command_runtime=24.54s

both with command_return_code=1 and empty stderr. Reading the
indexed log streams returns 0 events for these scripts' .err
streams — they didn't crash, they were killed by the composer's
per-step deadline while blocked inside 'nc -U' against the daemon's
control socket.

Likely path: under a specific fault window the daemon's accept loop
wedges (mid-reconnect / mid-deadlock during a network-partition or
node-pause event), 'nc -U -q 1' has no kernel-side timeout to bail
on, the composer wrapper's ~25s deadline fires, exit code propagates
as 1 — surfacing as a finding on the built-in 'Commands finish with
zero exit code' Always property.

Wrap each control-socket request in 'timeout --kill-after=2s 5s sh -c
"..."' so any blocked nc is bailed out within 5s + 2s SIGKILL grace,
the empty-RSP branch hits the 'tx_generator_*_daemon_unreachable'
Reachability marker, and the script exits 0. The underlying daemon
wedge is a separate ticket on the upstream cardano-node-clients repo
— this composer fix masks the symptom so the testnet baseline isn't
contaminated by it.

The two adversary docs described the long-running daemon shape that
was retired in #110. Rewrites both pages to match the current state:

- adversary.md — sleep-forever container, single CLI per tick, single
  driver with --target-host fan-out over all 5 cluster hosts,
  --seed-driven random pick. New CLI flag table. New compose
  fragment. Local test loop via scripts/smoke-test.sh
  cardano_node_adversary. Closing section explains why the daemon
  was retired (two schedulers, targeting bias, lifecycle complexity
  for no benefit).
- adversary-roadmap.md — restructures around CLIs, not endpoints.
  Each future archetype is one binary + one driver, not a new daemon
  endpoint. Tier list preserved; "what's behind us" replaces the
  daemon-era status table. Tickets section reflects the closures
  done in PRs #110 and #122.

Also drops the dead adversary-CI.yaml badge from the top README —
that workflow was retired in 9bc9b23.

Rebases on current main (which now has the workflow inputs.test fix
e3b09a0 and the publish-images all-testnets glob 81f3bf1, so the
sibling publish workflow + script from earlier iterations of this
branch are dropped). Master-side files (testnets/cardano_node_master/,
scripts/, master workflows) are untouched.

Adds:

  * testnets/cardano_node_tx_generator/{docker-compose.yaml,
    testnet.yaml,relay-topology.json,tracer-config.yaml,README.md}
    — mirrors master's image set 1:1 (cardano-node x3 by digest,
    cardano-tracer by digest, configurator/log-tailer/tracer-sidecar
    by digest, sidecar:65039df) plus the tx-generator service
    active. Network name 'cardano-node-tx-generator-testnet' to
    avoid collision with master's network when both run on the
    same docker daemon.
  * components/tx-generator/flake.nix bumped to upstream
    711eb22ac03e67b753f7ce70e635cddcf6f3cdce — full
    reconnect-resilience stack: PR #105 (supervisor +
    BlockedIndefinitelyOnSTM catch), #110 (post-reconnect indexer
    freshness gate), #114 (pre-submit chain-tip probe), #115
    (refill duplicate-submit recovery), #116 (recovery-await timeout
    aligned with dcAwaitTimeoutSeconds), #117 (refill recovery-await
    timeout -> IndexNotReady), #118 (same recovery in transact arm).
  * Composer scripts hardened (set -u, always exit 0, lastTxId gate
    on did_not_grow).
  * docs/components/tx-generator.md — daemon architecture: composer-
    as-clock contract, deterministic per-request flow, single-bearer
    N2C topology with in-tree address-to-UTxO indexer, NDJSON wire
    schema with response classes, per-request build/probe/submit/
    recovery flow, reconnect-resilience PR stack, composer scripts
    convention, persistent state, assertion classes.
  * docs/testnets/cardano-node-tx-generator.md — testnet rationale,
    image-set parity table with master, dispatch invocations, ref to
    the repo-wide publish-images flow.
  * mkdocs.yml — Components and Testnets nav entries.

Verified clean on a 1h no-faults Antithesis dispatch:
findings_new=0, all tx_generator_*_landed assertions firing, no
tx_generator_*_submit_rejected. Compose tag in this commit is
PLACEHOLDER; the next commit on this branch sets it to this commit's
SHA so publish-images.sh can resolve it as a downstream commit ref.

`hashedInstalledPackageId` selects between Long / Short / VeryShort
unit-id formats based on `buildOS` — the OS where cabal-install is
currently executing.  For haskell.nix that's the *eval* platform of
the plan-nix derivation, not the *build* platform where cabal will
later actually do the compile.  When the two differ (e.g. evaluating
on Darwin while building x86_64-linux derivations), plan-nix unit-ids
diverge from the unit-ids slice cabal v2-build computes — every slice
then tries to rebuild every dep from source.

Add a `CABAL_INSTALLED_PACKAGE_ID_OS` env var that overrides
`buildOS` for unit-id format selection.  haskell.nix sets it to the
build platform's OS when invoking `make-install-plan`.

Two new docs pages:

- docs/components/tx-generator.md — describes the daemon's role
  (composer-as-clock, deterministic per-request, monotonic
  population growth), the in-process N2C topology (single bearer
  for ChainSync + LSQ + LTxS, in-tree address-to-UTxO indexer),
  the NDJSON wire schema with response classes (Ok / IndexNotReady
  / NoPickableSource / SubmitRejected), the per-request
  build → pre-submit probe → submit → post-submit recovery flow,
  the reconnect-resilience PR stack (#105/#110/#114/#115/#116/#117/#118)
  and what each PR contributes, the composer scripts and the
  always-exit-0 + set -u rule, persistent state on disk, and the
  hard-failure vs reachability assertion classes.

- docs/testnets/cardano-node-tx-generator.md — sibling testnet
  rationale (master is read-only on feature branches), image-set
  parity table with master, network topology mirror (3-pool
  + 2-relay; tx-generator → relay1 over single N2C bearer),
  local-run + Antithesis-dispatch invocations, the sibling
  publish-images workflow, and the master-promotion pattern.

mkdocs.yml updated with both pages in the Components and Testnets
nav sections respectively.

Bumps cardano-node-clients SRP + flake input from 9db6672a (PR
#113 merge) to 428313de (PR #120 merge).

Upstream lambdasistemi/cardano-node-clients PR
https://github.com/lambdasistemi/cardano-node-clients/pull/120
folds in three things this branch surfaced:

  - Issue #119 fix: setUpstreamStatus's UpstreamConnected branch
    now re-derives rsReady from current rsSlotsBehind, so a
    reconnect to a chain at the indexer's last seen tip flips
    ready=true immediately instead of waiting for the next
    rollForward (which never came under fault injection on a
    short-test 1h run).

  - Issue #121 CI gap: nix/checks.nix + ci.yml + justfile now
    run the unit-tests suite. The 244-example suite had not
    been executed by upstream CI; the conservation regression
    (next item) had been red on origin/main since 9db6672a.

  - Issue #121 fix: TxBuild's post-balance evaluator no longer
    bails with EvalFailure on a script-conservation violation —
    it iterates with the balanced body as the new prevTx so
    Peek-driven scripts re-read the post-balance fee. Mirrors
    the pre-balance eval-failure retry path. Bounded by
    seenFees cycle detection.

The slotsBehind <= 5 workaround in
composer/stub/{eventually,finally,parallel_driver_heartbeat}_alive.sh
is left in place — it remains a more direct expression of "the
indexer is keeping up" and is now consistent with the upstream
fix (both check the same condition; one in Haskell, one in
bash). Reverting it is unnecessary.

Run 3's report flagged 'stub finally_alive holds' as
sdk_sometimes False, with last_reply
{processedSlot:60, ready:false, slotsBehind:0, tipSlot:60} —
the indexer was *at the chain tip* (processedSlot==tipSlot,
slotsBehind=0) but its 'ready' boolean was still false.

The indexer's 'ready' flag has stricter semantics than
slots-behind-the-tip: it requires lifecycle events past the
ChainSync warmup (likely "have I received at least one
RollForward since (re)connection"). Under fault injection,
relay1 frequently restarts and the indexer reconnects via the
PR #98 supervisor; if the chain is at a settled tipSlot when
the indexer reattaches, processedSlot catches up via RollBack
without a subsequent RollForward, leaving 'ready=false' until
the next block lands.

The asteria-side scripts only mean to assert "the indexer is
keeping up with the chain". slotsBehind<=5 captures that
exactly (matches --ready-threshold-slots default) and is robust
to the warmup race. The 'ready' boolean is the indexer's
stricter self-assessment and is racy under fault injection.

Same fix applied to eventually_alive.sh, finally_alive.sh, and
parallel_driver_heartbeat.sh — they all had the same overstrict
check.

After rebasing on origin/main this commit makes
testnets/asteria_game/docker-compose.yaml exactly equal to
testnets/cardano_node_master/docker-compose.yaml in its first
197 lines, plus a single asteria-game service block and the two
asteria-specific named volumes (asteria-game-db, asteria-deploy)
appended.

The asteria_game testnet is now provably:

  cardano_node_master + the asteria-game container

Anything that holds on master should hold here; anything that
breaks on master is master's concern. The
chain-sync-client/parallel_driver_flaky_chain_sync.sh and
convergence/finally_tips_agree.sh failures we saw on runs 1 and 2
appear on cardano_node_master 1h scheduled runs too — they are
inherited from master, not introduced by asteria.

Also carries over tx-generator.disabled.yaml verbatim from
master, even though this testnet had already removed
tx-generator earlier — keeps the directory contents symmetric so
"how to re-enable tx-generator on asteria_game" is the same
exercise as on master.

The compose tag still points at c99e992 (BootstrapMain
top-level catch — the only asteria-side defensive fix that
survived the cleanup).

testnets/cardano_node_master/docker-compose.yaml was bumped to
sidecar:65039df on origin/main in commit dcef9bc, which drops the
orphan chain-sync-client/parallel_driver_flaky_chain_sync.sh
probe baked into older sidecar images. Rebasing pulled that
master-side change in for the cardano_node_master testnet but
left this testnet's sidecar at the prior f889dbc — restoring the
"asteria_game = master + asteria-game container" invariant
requires bumping it here too.

This is also the asteria-side reason that finding kept showing
up in runs 1, 2 and 3: each used sidecar:f889dbc which still
bakes the orphan driver. With sidecar:65039df the orphan is gone
and the inherited finding should disappear in run 4.

Walked back the sidecar drop. The asteria_game testnet is
cardano_node_master + the asteria-game container; the cluster
infrastructure (sidecar / convergence / chain-sync-client) must
hold under fault regardless of what asteria does. Whatever
asteria introduces — utxo-indexer load on relay1, spawn tx
churn — has to be the thing fixed, not the cluster's
invariants.

Also strips the runtime-mount workarounds added to the sidecar
block (the ./no-op-finally.sh bind-mount and the
chain-sync-client tmpfs override). They were inert anyway —
Antithesis's composer discovers driver scripts at image-bake
time, not container-runtime — so leaving them only created
cargo-cult clutter.

Compose tag bumped to c99e992 (BootstrapMain top-level catch),
which is the only legitimate fix from the previous attempt.

This reopens the question raised by run 2: are
convergence/finally_tips_agree.sh and chain-sync-client/
parallel_driver_flaky_chain_sync.sh failing because relay1 is
falling behind p1/p2/p3 under load from the asteria-game
container's utxo-indexer ChainSync? If so, the fix is in
asteria-game (don't stress relay1), not in dropping the
checks.