Cardano Updates

Two compounding bugs across all asteria-game test scripts:

1. socat (eventually_alive, finally_alive, parallel_driver_heartbeat)
   and the asteria-* binaries (asteria_player, admin_singleton,
   bootstrap, asteria_consistency) have no internal deadlines.
   Composer's per-command cap is ~16 s for parallel/eventually,
   ~54 s for finally. When upstream stalls (indexer slow to reply,
   N2C handshake hung under partition, container restart), the
   wrapping bash gets SIGKILLed BEFORE the binary returns; the
   sdk_run_signal_safe wrapper never executes its rc check;
   composer assigns synthetic exit 1 and flags the script under
   "Always: Commands finish with zero exit code". Fix: every
   external call now has an explicit `timeout N` wrapper sized
   under composer's per-command-type cap (1 s for socat probes,
   12 s for parallel/anytime, 25 s for serial, 30 s for finally
   binary; 10 s settle for the consistency check, total 40 s).

2. sdk_run_signal_safe absorbed signal-induced exits via
   sdk_unreachable, but AlwaysOrUnreachable with hit:true +
   condition:false IS a finding. Now uses sdk_sometimes_optional
   (must_hit:false) so absorbed signals are observation-only.
   Same precedent as PR #137's eventually_alive cold_start fix.

Smoke-tested locally — `timeout 0.1 sleep 5` exits 124 →
sdk_run_signal_safe maps it to a Sometimes/must_hit:false event
and returns 0; the JSONL emit shows must_hit:false as expected.

Together this addresses every finding category we saw in the
multi-run flake survey:
  - Always: Commands finish with zero exit code (× 3 scripts)
  - Always: stub eventually_alive cold_start (handled in PR #137)
  - Sometimes: stub eventually_alive cold_start (handled in PR #137)

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

The test runs `runghc conduit-test.hs` inside the v2 shell; that
needs `Conduit` visible to plain `ghc`/`runghc`.  Default
`exposePackagesVia = "cabal-store"` only seeds `~/.cabal/store`
(which `cabal v2-build` reads), so plain ghc still misses the
setup-deps.  Switch to `"ghc-pkg"` so the wrapped ghc stacks the
composed package.db via `GHC_ENVIRONMENT`.

since this is now part of the `StAnnTx` signal

The previous commit treated every project package as "iterated on
from the working tree" and excluded them all from the shell's
cabal store.  That broke `tests.cabal-sublib-shell.run`, which
intentionally selects just `consumer` and expects `provider` (a
sibling project package) to be pre-built — so an unpatched cabal
inside the shell can reuse provider's lib/sublib instead of
rebuilding from source.

Mirror v1's `removeSelectedInputs` semantics: only exclude packages
in `selectedPackages` itself.  With the default
`packages = selectProjectPackages` every project pkg is selected
(so the cardano-wallet UX is unchanged); with an explicit
`packages = ps: [ ps.foo ]`, only `foo` is excluded and sibling
project pkgs land in the store.

Also drops the project-pkg closure walk — `selectedPackages`
already enumerates every unit-id fragment, so a straight
`concatMap getAllComponents` covers all components without the
walk.

This commit adds serialization roundtrip tests for the concrete Peras
votes and certificate types.

Co-authored-by: Agustin Mista <[email protected]>
Co-authored-by: Thomas BAGREL <[email protected]>
Co-authored-by: Nicolas BACQUEY <[email protected]>

This commit adds conversion rountrip tests between concrete Peras votes
and certificates and their corresponding (abstract) counterparts in the
WFALS and EveryoneVotes voting committee implementations.

Notably, the roundtrip properties allow testing both total (WFALS) and partial
(EveryoneVotes) conversions, generating both good and bad cases and
contrasting them against their expected rountrip outcome.

Co-authored-by: Agustin Mista <[email protected]>
Co-authored-by: Thomas BAGREL <[email protected]>
Co-authored-by: Nicolas BACQUEY <[email protected]>

This commit defines a concrete PerasCrypto scheme using BLS signatures
to instantiate all the voting committee superclasses needed by the WFALS
and EveryoneVotes voting committee implementations.

Note that these instances are heavily inspired by the ones defined for
TestCrypto in the generic voting committee test-suite, albeit with
slightly different types and more documentation.

Co-authored-by: Agustin Mista <[email protected]>
Co-authored-by: Thomas BAGREL <[email protected]>
Co-authored-by: Nicolas BACQUEY <[email protected]>

Co-authored-by: Agustin Mista <[email protected]>
Co-authored-by: Thomas BAGREL <[email protected]>
Co-authored-by: Nicolas BACQUEY <[email protected]>