Cardano Updates

The cardano-node.yaml workflow declared a workflow_dispatch `test`
input ('Test configuration to run (a directory in testnets)') but
the env block hardcoded TESTNET=cardano_node_master, so the input
was silently ignored. Every dispatch — regardless of -f test=… —
sent cardano_node_master's image set to Antithesis.

Caught by the run on dae3a5b targeting cardano_node_tx_generator:
the tx-generator image was missing from antithesis.images and no
tx_generator_* assertions appeared in the report. Confirmed by
diffing the docker-compose.yaml of cardano_node_tx_generator (which
includes the tx-generator service) against the actual image set
sent to Antithesis (which did not).

Bind TESTNET to inputs.test with a cardano_node_master fallback so
the cron schedule (which has no inputs) keeps targeting master.

Register both UTxORPC v1alpha and v1beta service implementations on the
same listener. Clients pick which proto package they call; on the wire
the two are entirely separate gRPC services (utxorpc.v1alpha.* vs
utxorpc.v1beta.*), so no routing logic is needed and v1alpha bytes stay
unchanged.

Layout:
- src/serve/grpc/v1alpha/{query,sync,watch,submit}.rs - moved from
  src/serve/grpc/, imports rewritten to explicit pallas v1alpha paths.
- src/serve/grpc/v1beta/{query,sync,watch,submit}.rs - copies with
  imports swapped to v1beta. The only body divergence is in
  v1beta/query.rs read_utxos, where Datum.original_cbor is
  Option<Bytes> rather than Bytes.
- mod.rs: registers eight server impls (4 services x 2 versions) and
  10 file descriptor sets in tonic reflection.

Cargo.toml: bumps pallas to git rev 0da71c2 to pick up v1alpha and
v1beta proto packages and the v1beta::Mapper.

Drive-by: drop unused _mapper field from SubmitServiceImpl, and remove
two stale commented-out blocks in sync.rs.

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.

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.

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).

Closes the always-true admin_mint placeholder PR #67 ships. The
bootstrap's "no double-mint on container restart" contract was
previously enforced only by the off-chain isAlreadyDeployed
check; this commit puts the contract on chain.

Aiken side (components/asteria-game/aiken/validators/admin_mint.ak):
  - validator admin_mint(seed: OutputReference) succeeds iff the
    tx consumes the seed AND the bundle minted under this policy
    is exactly [(asteriaAdmin, 1)]. Seed consumption is permanent
    on Cardano UTxO, so admin_mint can fire at most once across
    all chain history.
  - aiken/plutus.json regenerated; admin_mint now declares one
    parameter "seed". All 91 existing tests pass.
  - apply-params.sh / plutus-applied.json no longer in the build
    path — Haskell applies the seed at runtime.

Haskell side:
  - new Asteria.Validators.applyScripts: takes a seed TxIn and
    returns AppliedScripts { adminMint, pellet, asteria,
    spacetime } with both Plutus scripts and ledger-side hashes.
    Built on plutus-ledger-api's uncheckedDeserialiseUPLC +
    UntypedPlutusCore.applyProgram + serialiseUPLC. Hash
    dependencies are threaded in declaration order
    (admin_mint → pellet → asteria → spacetime).
  - new Asteria.Deploy module: read/write
    /asteria-deploy/seed.json. Bootstrap is the only writer;
    player + invariant are readers. ASTERIA_DEPLOY_DIR env var
    overrides the path.
  - BootstrapMain: reads seed.json on startup. If present,
    re-derives the same scripts (deterministic). If absent,
    picks a fresh wallet UTxO via pickWalletUtxo, writes the
    seed to disk BEFORE submitting the deploy tx (durable order
    so a crash leaves either no file or a consistent file).
    isAlreadyDeployed simplified to "any UTxO at the per-deploy
    asteria addr" — under the one-shot policy at most one such
    UTxO can ever exist.
  - PlayerMain + InvariantMain: read seed.json, applyScripts,
    use AppliedScripts.as{Asteria,Spacetime,Pellet,AdminMint}
    {Script,Hash} in place of former top-level constants. If
    seed file missing, emit asteria_*_seed_missing_<id>
    sdkUnreachable and exit cleanly (correct: bootstrap hasn't
    run yet on this cluster).

Compose:
  - new asteria-deploy named volume mounted at /asteria-deploy
    on the asteria-game container.

Locally validated end-to-end on testnets/asteria_game/:
  - pre-bootstrap: asteria_invariant_seed_missing_admin_singleton
    fires (correct)
  - bootstrap cold: asteria_bootstrap_seed_picked +
    asteria_bootstrap_seed_persisted + asteria_bootstrap_asteria_created
    (asteria addr is now per-seed: 77a02b8e... instead of the
    previous hardcoded 0824601a...)
  - container restart: asteria_bootstrap_seed_reused +
    asteria_bootstrap_already_deployed short-circuit
  - spawn: asteria_player_ship_spawned_1 succeeds with the
    seed-derived validators
  - consistency: ship_counter=1, ship_token_count=1, hit=true
  - admin_singleton: count=1, hit=true (post-bootstrap and
    post-spawn)

Run 2 (commit 483d327) on testnets/asteria_game/ surfaced 3 new
findings, two of which were unchanged from run 1:

  1. stub/serial_driver_asteria_bootstrap.sh — non-zero exit
  2. chain-sync-client/parallel_driver_flaky_chain_sync.sh —
     non-zero exit
  3. convergence/finally_tips_agree.sh — non-zero exit (rc=101)

(1) Bootstrap continued to fail because `withN2C` and other
calls *outside* runDeploy's local try block could still throw
(connection failures, transient queryUTxOs errors when relay1
is being faulted, etc.). Antithesis treats every non-zero exit
as a real "Always: zero exit code" violation regardless of
subsequent successful fires. Wraps the entire post-startup body
(everything after the `_starting` and `_wallet_loaded` SDK
events) in `try`; on any uncaught exception fires
asteria_bootstrap_deferred (sdkSometimes True) and exits 0.

(2) and (3) failed because the prior compose-level mounts
(tmpfs over /opt/antithesis/test/v1/chain-sync-client and
bind-mount of a no-op over convergence/finally_tips_agree.sh)
have no effect — Antithesis's composer discovers driver scripts
at image-bake time, not at container-runtime, so per-service
mounts are ignored. The convergence finding was rc=101 instead
of "missing" because the composer ran the original baked
version, not the bind-mounted no-op.

The proper fix is to drop the sidecar service entirely from
this testnet's compose. The sidecar:f889dbc image is the *sole*
source of both /opt/antithesis/test/v1/convergence/ and
/opt/antithesis/test/v1/chain-sync-client/ scripts. With no
sidecar container the composer has no host for those drivers
and they disappear from the run. Tracer / tracer-sidecar /
log-tailer remain (none of those bake composer scripts) so
report observability is preserved.

testnets/asteria_game/no-op-finally.sh is removed (it was a
runtime-mount workaround that didn't take effect).

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.

Adds testnets/asteria_game/no-op-finally.sh and bind-mounts it
over the sidecar:f889dbc image's
/opt/antithesis/test/v1/convergence/finally_tips_agree.sh.

That driver enforces "all producer tips at exact same slot at
end-of-run" via an SDK Always assertion. On 1h runs under fault
injection the tips drift recovers slowly after faults stop and
the check fires false purely on duration, not on a real
reconvergence bug. The check is also orthogonal to the asteria
game contract this testnet scores — asteria observes the chain
through relay1 and tolerates short-lived tip lag.

Other convergence drivers (eventually_converged,
parallel_driver_tip_agreement, serial_driver_tip_agreement) are
unaffected and continue to run from the unmodified sidecar
image. Their during-fault and probabilistic checks remain a
real cluster-health signal.

The "test" workflow_dispatch input was declared but never read —
TESTNET was hardcoded at the env level. With this one-line fix,
manual dispatches can target any testnets/<dir> (e.g.
testnets/asteria_game/) while the cron schedule keeps its
default of cardano_node_master.

The sidecar:f889dbc image bakes
/opt/antithesis/test/v1/chain-sync-client/parallel_driver_flaky_chain_sync.sh
which expects the adversary daemon — a separate component absent
from this testnet. Without it the script fails (exit 1) on every
fire and trips Antithesis's "Always: zero exit" property.

Mounting tmpfs over the chain-sync-client/ path on the sidecar
container hides the script from the composer at start time
without modifying the upstream image. Newer sidecar tags have
the script removed at the source but introduce Amaru-specific
drivers that would fail on this Amaru-less testnet — net no
gain. The targeted shadow is the cleanest fix.

Bumps the asteria-game compose tag to d0d9531 (drivers exit 0
on transient not-yet-ready conditions).

The Antithesis 1h dispatch on testnets/asteria_game/ surfaced
two "Always: Commands finish with zero exit code" findings on
stub/serial_driver_asteria_bootstrap.sh and
stub/parallel_driver_asteria_player.sh. Decoded composer events:

  - bootstrap: t=62.76s rc=1 (6.14s), t=106.5s rc=1 (52s),
    t=110.5s rc=1 (55s), t=178.5s rc=0 (3s short-circuit)
  - player: t=54.4-54.6s rc=1 (3 fast failures, ~5-15ms each),
    t=249.9s rc=0 (3.04s)

The early bootstrap failures hit before the cluster forged its
first block (build/sign/submit fails on protocol-params or
validity-interval errors). The player failures are PlayerMain
calling `error` when seed.json is missing — the parallel driver
fires before bootstrap completes.

Antithesis treats every non-zero exit as an Always-violation,
regardless of subsequent successful fires. This commit makes
both drivers exit 0 on transient "not yet ready" conditions:

  - PlayerMain: when readSeed returns Nothing, fire
    asteria_player_seed_missing_<id> (sdkUnreachable, already
    present) and return cleanly. The next composer fire retries.
  - BootstrapMain.runDeploy: catch any exception from
    resolveSeed / createAsteria, fire
    asteria_bootstrap_create_asteria_deferred (sdkSometimes True)
    with the error string, and return cleanly. Subsequent fires
    re-derive the same seed (deterministic via seed.json) and
    retry — the seed UTxO is preserved when the failure is
    pre-submit, and consumed cleanly when the deploy actually
    landed (next fire short-circuits via isAlreadyDeployed).

The signals Antithesis cares about — whether the deploy ever
succeeded, whether the singleton invariant held — still flow
through the existing sdkSometimes / sdkAlways assertions. We
just stop using process exit code to encode "world not yet
ready", which Antithesis interprets as a real bug.

The tx-generator daemon produces background transaction traffic.
On testnets/asteria_game/ we explicitly want the asteria game's
own spawnShip / move / mine / quit traffic to be the only chain
activity — anything else is noise that distorts the report's
view of the workload we're scoring.

Service list now: configurator (one-shot), p1/p2/p3 producers,
relay1/relay2 relays, tracer, tracer-sidecar, sidecar,
log-tailer, asteria-game. Observability + chain telemetry
preserved; only the synthetic-traffic generator removed.

This reverts commit 80aaa6e37ba42b49172e1acbbb4ce2a2f7387573.

After the first spawn, the genesis wallet has two UTxOs at its
address: a small change output (~9.5 ADA) and the original genesis
UTxO. The previous "first UTxO" selection picked the change one
on subsequent passes, and the spawn tx then failed
@BalanceFailed InsufficientFee@ because the change output's
lovelace was below the required fee + outputs.

New rank: pure-ada UTxOs first (so balanceTx's change doesn't
have to carry token dust), then by descending lovelace. With this,
back-to-back spawn passes now both succeed and ship_counter
advances 1 → 2 in sdk.jsonl on the local cluster.

(Concurrent passes within the same slot can still race on
ConwayMempoolFailure "All inputs are spent" — that's a pacing
artifact of the local-test cadence, not a problem under the
Antithesis composer's natural per-driver gap.)