Cardano Updates

PR 2: make rerunning bootstrap safe. Antithesis can restart the
asteria-game container at any time; serial_driver_asteria_bootstrap
will re-fire on each restart. The Haskell binary now skips the
mint+lock if the asteria spend address already carries a UTxO with
the asteriaAdmin token.

Defence layers in place after this PR:
  1. Haskell-side detection (this PR): Provider.queryUTxOs at the
     asteria spend address; presence of (admin_mint_hash,
     "asteriaAdmin") = already deployed → exit 0 with
     sdk_sometimes("asteria_bootstrap_already_deployed").
  2. Antithesis serial_driver scheduling: exclusive access while
     bootstrap runs → no concurrent invocations on the same timeline.

KNOWN GAP — defence layer 3 (Plutus one-shot) is still on the
todo list. PR #67's admin_mint validator is the always-true
placeholder, so there is no chain-level uniqueness guarantee yet.
A future PR replaces admin_mint with a parameterised one-shot
that consumes a seed OutputReference; until then the indexer
race window between detection and submission, while small under
serial_driver scheduling, is non-zero. See spec FR-010 / User
Story 4.

New: composer/stub/serial_driver_asteria_bootstrap.sh — exec
/bin/asteria-bootstrap. Antithesis discovers it under
/opt/antithesis/test/v1/stub/ (already mounted via the same
docker-image build).

PR 2: make rerunning bootstrap safe. Antithesis can restart the
asteria-game container at any time; serial_driver_asteria_bootstrap
will re-fire on each restart. The Haskell binary now skips the
mint+lock if the asteria spend address already carries a UTxO with
the asteriaAdmin token.

Defence layers in place after this PR:
  1. Haskell-side detection (this PR): Provider.queryUTxOs at the
     asteria spend address; presence of (admin_mint_hash,
     "asteriaAdmin") = already deployed → exit 0 with
     sdk_sometimes("asteria_bootstrap_already_deployed").
  2. Antithesis serial_driver scheduling: exclusive access while
     bootstrap runs → no concurrent invocations on the same timeline.

KNOWN GAP — defence layer 3 (Plutus one-shot) is still on the
todo list. PR #67's admin_mint validator is the always-true
placeholder, so there is no chain-level uniqueness guarantee yet.
A future PR replaces admin_mint with a parameterised one-shot
that consumes a seed OutputReference; until then the indexer
race window between detection and submission, while small under
serial_driver scheduling, is non-zero. See spec FR-010 / User
Story 4.

New: composer/stub/serial_driver_asteria_bootstrap.sh — exec
/bin/asteria-bootstrap. Antithesis discovers it under
/opt/antithesis/test/v1/stub/ (already mounted via the same
docker-image build).

PR 1 of 2 toward the real asteria workload. Scope-limited to the
rename + Haskell source lift + nix scaffolding so the binaries
build alongside the existing utxo-indexer. Bootstrap is iteration
5b — *not safe for repeat invocation* — that gap is explicitly the
subject of PR 2.

Rename:
  components/asteria-stub/ → components/asteria-game/
  service asteria-stub      → asteria-game
  volume  asteria-stub-db   → asteria-game-db

Lift from cardano-foundation/cardano-node-antithesis#67 (asteria-spawn-v2):
  components/asteria-game/aiken/         (validators + apply-params)
  components/asteria-game/src/Asteria/   (game state, datums, validators, wallet, providers, RNG, SDK)
  components/asteria-game/app/{BootstrapMain.hs, PlayerMain.hs}
  components/asteria-game/asteria-game.cabal      (renamed package)
  components/asteria-game/cabal.project           (cardano-node-clients SRP bumped to PR #98 head 5707836b)

Build infra:
  flake.nix — extends prior asteria-stub flake with haskell.nix /
    iohk-nix overlays so local Haskell packages compile, while
    keeping the upstream cardano-node-clients flake input that
    supplies the prebuilt utxo-indexer (PR #98 supervisor).
  nix/project.nix — lifted from PR #67, package renamed.
  nix/docker-image.nix — bundles utxo-indexer + asteria-bootstrap
    + asteria-game (player) execs + composer scripts + bash/jq/
    socat; entrypoint stays utxo-indexer.

KNOWN GAP — admin_mint validator is the always-true placeholder
PR #67 ships. Without an on-chain one-shot guarantee, every
container restart could mint another admin NFT. Bootstrap is *not*
wired into compose in this PR for that reason. PR 2 patches the
Aiken admin_mint to take an OutputReference parameter, runs
apply-params at bootstrap-time, and adds defence-in-depth detection
in Bootstrap.hs.

Composer scripts (composer/stub/{parallel_driver_heartbeat,
eventually_alive, finally_alive, helper_sdk}.sh) unchanged from
the green stub baseline so this PR stays bisect-safe and in
property terms identical to commit 3b6fb0e (PR #74's merged head).

Co-authored-by: Copilot <[email protected]>
Signed-off-by: jeluard <[email protected]>

Feature/add-proxy-api-and-ci-testing

This check that was introduced for the protocol version in the block header
proved to be problematic for testnets. Which makes sense, since it was
designed for mainnet in mind and its introduction was needed to be done
urgently since it was blocking 10.6.2 release. See #5595 for more context

In order to allow for testnets to continue being able to produce blocks
for older protocol versions with latest version of the node we lift this
restriction, but only for any network with `Testnet` network id. This is
implemented as a temporary measure and will be properly fixed in
Dijkstra era. See #5763 for more context

* Verification of `PrevGovActionId` in `proposalsAddAction` happens on
  accumulated `proposals`
* While `preceedingHardFork` check happens on original `st`.

In a usual application, which has identifiers assigned, this inconsistency
would have been a problem. However, in a transaction's `GovActionId`, which is
derived from a hash of a transaction itself, it is impossible to reference
a previous governance action within the same transaction, since one would need
to know the hash of a transaction that contains the proposal it tries to
reference.

Therefore, this commit fixes not an issue, but a mere inconsistency.
This is done in order to avoid developers even considering this edge case.

Co-authored-by: Copilot <[email protected]>
Signed-off-by: jeluard <[email protected]>

- Updated proxy lifecycle scenarios to include support for hierarchical wallets alongside legacy and SDK wallets.
- Modified README documentation to reflect changes in wallet type coverage for proxy full lifecycle scenarios.
- Improved error handling in proxy setup finalization to ensure valid transaction hashes.
- Added unit tests to validate new hierarchical wallet functionality in proxy management.
- Adjusted existing tests to ensure comprehensive coverage of all wallet types in proxy lifecycle processes.

* Verification of `PrevGovActionId` in `proposalsAddAction` happens on
  accumulated `proposals`
* While `preceedingHardFork` check happens on original `st`.

In a usual application, which has identifiers assigned, this inconsistency
would be a problem. However, in a transaction`GovActionId` is derived from
a hash of a transaction itself. This means that it is impossible to reference
a previous governance action within the same transaction, since you'd need to
know a hash of a transaction that contains the proposal itself.

Therefore, this commit fixes not an issue, but a mere inconsistency.
This is done in order to avoid developers even considering this edge case.

The Schnorr / Ed25519 / ECDSA Hedgehog property tests in
plutus-core/untyped-plutus-core/testlib/Evaluation/Builtins/SignatureVerification.hs
asked Hedgehog to enforce a 4-5% distribution per labelled outcome,
which is barely above noise.

The generators use either Gen.choice or Gen.frequency 6:4 over an
error / no-error split, with 2-3 labelled sub-cases per side, so each
sub-case occurs roughly 13-20% of the time. Tightening the cover
threshold to 15 brings the bar in line with what the generators
actually produce while still flagging accidental skew.

This addresses the first half of #6332. The 'add real distribution-
checking tests' part is a separate follow-up.

Mirror the existing HEDGEHOG_TESTS upscaling for QuickCheck so nightly
property runs also exercise QuickCheck-based generators with a larger
sample count and size parameter.

* Add QUICKCHECK_TESTS / QUICKCHECK_MAX_SIZE env vars (defaults
  100000 / 500), plus matching workflow_dispatch inputs.
* Pass --quickcheck-tests / --quickcheck-max-size to every test
  invocation that already passes --hedgehog-tests.

These flags are recognised by tasty-quickcheck and only take effect
in the nightly run.