Cardano Updates

Signed-off-by: Eric Torreborre <[email protected]>

GitHub Actions emits a redirect notice on windows-latest jobs: "windows-2025 requests are being redirected to windows-2025-vs2026 by May 12, 2026".

Pin the Windows GitHub-hosted jobs to the new explicit label, including release E2E, standalone E2E, unit tests, and release-asset verification.

Stop auto-promoting nightly/test runs to GitHub's "Latest" pointer and
stop auto-undrafting real releases before notes are reviewed.

release.yml changes:
- gh release create passes --prerelease for nightly/test, so the GitHub
  API "Latest" lookup keeps following the most recent semver release
  instead of switching to nightly every night.
- publish-release auto-un-drafts only for nightly/test. For real
  releases it logs a notice and leaves the draft in place; the
  maintainer edits notes (Docker link, changelog, signatures) and
  clicks Publish in the GitHub UI.
- push-docker is skipped on the release path; the new
  publish-release.yml handles the version + latest docker push.
- update-docs is removed from release.yml; same new workflow handles
  the gh-pages redirect on release.published.

New .github/workflows/publish-release.yml:
- Triggered on release.published (filter: not prerelease).
- Downloads the docker-image asset from the release, pushes
  cardanofoundation/cardano-wallet:<tag> and :latest to Docker Hub.
- Runs releases/make_redirects.sh on gh-pages with the release tag.

Mirrors the fix→chore pattern of #143 / #146. Without this bump the
next Antithesis run would still pull the previous :126bb4e image
where the composer scripts live at /opt/antithesis/test/v1/stub/,
and the renamed paths in the docker-compose mounts would not match.

Re #144.

Closes #144.

The directory was lifted verbatim from components/asteria-stub/ in
fbb8982 ("asteria-game: testnet split + lift PR #67 source +
idempotent bootstrap (#100)") when the real asteria-game implementation
arrived. The "stub" label stuck despite the scripts inside no longer
being placeholders — they are the canonical drivers for heartbeat,
alive probes, asteria bootstrap / player / consistency / admin
singleton, plus their SDK observability.

The rest of the repo follows <component>/composer/<purpose>/:
  components/adversary/composer/chain-sync-client/  ← descriptive
  components/tx-generator/composer/tx-generator/    ← descriptive
  components/asteria-game/composer/stub/            ← stale (was)

This PR fixes that. The label was leaking into the Antithesis
report — every finding showed up as `stub/parallel_driver_X.sh` and
every assertion as `stub heartbeat ticked` etc. — which read as
"placeholder code being flaky" rather than "real driver". That
misreading actually happened during triage of #142.

Changes:
- git mv components/asteria-game/composer/stub
       components/asteria-game/composer/asteria-game
- All SDK assertion IDs in the renamed scripts: drop the "stub "
  prefix → "asteria_game " (matching tx-generator's snake_case
  component-prefix convention). 21 assertion IDs across 7 scripts.
- Prose comments in the renamed scripts: "stub script" / "sibling
  stubs" → plain wording, since the rename makes the original
  framing wrong.
- Path references in:
    docs/components/asteria-player.md
    docs/testnets/cardano-node-master.md
    testnets/cardano_node_master/docker-compose.yaml
    testnets/cardano_node_adversary/docker-compose.yaml
    testnets/asteria_game/docker-compose.yaml
  all updated for /opt/antithesis/test/v1/asteria-game/ and the
  source dir.

components/asteria-stub/ (the legacy component with the un-bounded
socat reference baseline) is left untouched.

Antithesis identity reset:
- composer commands: now identified as
  asteria-game/parallel_driver_heartbeat.sh etc., distinct from the
  archived stub/* identities. History bar restarts for these.
- SDK assertions: same — asteria_game heartbeat ticked is a fresh
  identity vs the archived stub heartbeat ticked.
- One-time cost; the payoff is permanently readable triage output.

Local smoke (renamed paths):
- 10 concurrent shells × 5 emits → 50 valid JSON lines
- SIGTERM mid-sleep → exit 0 with trap-emitted observation
- timeout --kill-after=2 escalation → exit 137 → absorbed

Mirrors the fix→chore pattern of #143 (444a1a5 → dfd6a3e). The
publish-images workflow rebuilds asteria-game at the SHA pinned in
each testnet's docker-compose; without this bump the next Antithesis
run would still pull the old :444a1a5 image and not exercise the
SIGKILL escalation.

Re #145.

Closes #145.

After #143 landed, six of seven previously-failing stubs went green
on the first post-merge cron of 8690faa, but
stub/parallel_driver_asteria_player.sh still tripped the
Always:zero-exit-code property with one new finding (3h 19m run,
faults on). Decoded examples:

  example 1  fail  rc=1  runtime 27.27 s
  example 2  fail  rc=1  runtime 28.65 s
  example 3  fail  rc=1  runtime 47.31 s
  example 4  pass  rc=0  runtime  3.02 s

The wrapper is `sdk_run_signal_safe ... timeout 12 /bin/asteria-game`.
Plain `timeout 12` sends SIGTERM at the 12 s deadline but does not
escalate to SIGKILL — that requires --kill-after. The Haskell
binary catches SIGTERM, runs slow N2C cleanup that fails on a
torn socket, then exits rc=1 (Haskell default unhandled-exception
code). sdk_run_signal_safe deliberately propagates non-signal
exits so the property fires.

Adding --kill-after=2 escalates to SIGKILL 2 s after SIGTERM. The
kernel-killed exit (137) is in sdk_run_signal_safe's absorb set
along with 124/129/143/255, so the script terminates deterministically
inside (deadline + 2) seconds and the property stays green.

Same shape on three sibling stubs that haven't tripped yet but
have the same wrapper pattern; fixed all four together to match
the failure mode rather than the run-by-run symptom:

  parallel_driver_asteria_player.sh   timeout 12 → --kill-after=2 12
  anytime_asteria_admin_singleton.sh  timeout 12 → --kill-after=2 12
  finally_asteria_consistency.sh      timeout 30 → --kill-after=2 30
  serial_driver_asteria_bootstrap.sh  timeout 25 → --kill-after=2 25

Local smoke (process that catches SIGTERM and runs slow cleanup):
  - plain timeout 1   → exit 124 sometimes, child rc otherwise (leaky)
  - --kill-after=2 1  → exit 137 reliably

No semantic change for healthy runs; failure path now terminates
predictably and is absorbed.

Refs #5275

- mark node freeze target extraction tasks complete
- record regenerated node 11.0.1 freeze evidence
- link upstream dependency tickets and draft PRs before wallet pins move

Refs #16

- align CHaP index-state and lock with cardano-node 11.0.1
- bump the Conway ledger constraint to the node 11.0.1 freeze
- harmonize the haskell.nix compiler with wallet ghc9123 and enable Hoogle

Refs #41

- align CHaP index-state and lock with cardano-node 11.0.1
- pin Cardano package constraints to the node 11.0.1 freeze surface
- harmonize the haskell.nix compiler with wallet ghc9123 and enable Hoogle

* Add test that demonstrates issue

* Final fixes

* Further bugs identified and fixes applied

* Further fixes

* Last fixes

* Last last fixes

* Abstract away ST token name

* Re-word some code-comments, test names

* Trace HeadOutputNotFound (D08) on missing head continuation

  Replace `expect Some(head_output) = list.find(outputs, has_ST(head_id))`
  inside `deposit_value_flows_to_head` with a `when … is` match. A tx that
  consumes a deposit without producing a head continuation (e.g. a Fanout-
  shape, or any malformed Increment) now logs an explicit `D08 /
  HeadOutputNotFound` followed by the wrapping `D07 /
  DepositValueNotInHead`, instead of aborting the script with an opaque
  `expect` failure trace.

  No behavioural change for honest Increments: a legitimate Increment
  always produces a head output, so the new `Some(head_output)` branch
  is the only one taken in the happy path.

* Use builtin.un_constr_data instead of mirror type

  Drop the HeadStateMarker type from deposit.ak and replace the
  `expect head_state: HeadStateMarker = d` decode + match in
  `head_output_is_open` with a direct
  `builtin.un_constr_data(d).1st == 0` check.

  The marker type only existed so the `expect` would succeed for any of
  the three legitimate State variants (Open / Closed / Final); we never
  constructed values of the Closed/Final variants ourselves, which is why
  Aiken kept warning that they were unused. Reading the constructor index
  directly captures the only thing we actually care about (variant 0 ==
  Open) and makes the positional-encoding dependency explicit at the call
  site instead of hiding it in a fake type.

  No behavioural change: a head_output whose datum is Closed or Final
  still returns False (and the wrapping D07 trace fires); a non-Constr
  inline datum still aborts the script (rare in practice and identical to
  the previous behaviour).

* Squash head_is_spent into deposit_value_flows_to_head

  `head_is_spent` and `deposit_value_flows_to_head`'s `head_input` lookup
  both walked the input list searching for the head's ST UTxO. The
  former returned a Bool used solely to gate the D06 trace; the latter
  re-found the same input via `expect Some(...)`. Collapse them: a single
  `when list.find(inputs, has_ST) is None -> trace D06 + False / Some(h)
  -> ...` lookup inside `deposit_value_flows_to_head` does both jobs.

  D06 still fires when the head ST input is missing (now from inside the
  function instead of from a standalone clause); D07 still wraps the
  whole check; D08 still fires on a missing head output. Behaviour is
  unchanged for honest and adversarial txs alike.

* Refresh plutus.json + script goldens, drop stale head_is_spent comments

* Hoist deposit value-flow check into checkIncrement

  The value equation -- "head_in + Σ deposit values == head_out" -- used
  to live in the deposit validator's deposit_value_flows_to_head. Each
  spending v_deposit input ran it independently. Now the head validator's
  checkIncrement runs it once, parameterised by the v_deposit script hash
  so it can identify deposit-script inputs by address credential.

  Motivation: stop running the same equation N times in a multi-deposit
  tx, and lay groundwork for off-chain batch deposits.

* Tidy deposit-security comments; drop before/after-fix framing

* Add mutation tests

* Drop redundant module header, rename attacker

* Tighten exception checks in SecurityScenarios

* Assemble a mutation for ingesting a wrong deposit input

* PR review

* Additional deposit-stealing increment test

* Enforce that all script inputs contribute to head value in Increment

  Every script input's value must be absorbed into the head output, so an attacker
  cannot smuggle an extra deposit input and redirect its value.

* Further fixes and PR feedback

* Check the redeemer in the deposit script

Now you can only claim a deposit during increment.

* Update scripts

* Changelog

---------

Co-authored-by: Sasha Bogicevic <[email protected]>

since this is now part of the `StAnnTx` signal