Cardano Updates

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

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

Convert top-level AsciiDoc documentation to GitHub-Flavored Markdown so
links render correctly on GitHub.

* README.adoc      -> README.md
* CONTRIBUTING.adoc -> CONTRIBUTING.md
* RELEASE.adoc     -> RELEASE.md
* STYLEGUIDE.adoc  -> STYLEGUIDE.md

Update cross-references in:
* DESCRIPTION.md
* plutus-benchmark/marlowe/README.md
* .github/copilot-instructions.md

Drop *.adoc target from scripts/check-broken-links.sh.

Conversion done with downdoc; output reviewed and adjusted for
asciidoc-specific markup (link:[...], {outfilesuffix}, anchor-style
headings).

Closes #6023

`applyDirectDeposits` uses `∪⁺` (union-with-addition) on the `rewards`
map, so a credential not present in `RewardsOf certState₂` is added as a
new entry rather than rejected.  The pre-existing SUBUTXO/UTXO premise
`dom (DirectDepositsOf tx) ⊆ dom (AccountBalancesOf Γ)` only checks
against the pre-batch balances `RewardsOf certState₀`, so it does not
catch the case where a credential is registered pre-batch, deregistered
during `CERTS`, and direct-deposited to in the same batch.  Without the
new premise, the resulting `certStateFinal` is internally inconsistent:
the credential has a positive `rewards` entry but no corresponding
`voteDelegs`, `stakeDelegs`, or `deposits` entry — effectively re-
registering the credential without a key deposit.

Add the phase-1 premise

    dom (allDirectDeposits tx) ⊆ dom (RewardsOf certState₂)

to `LEDGER-V` to rule this out.  Filtering `allDirectDeposits tx` by
`dom (RewardsOf certState₂)` would be an alternative, but it would
silently destroy user funds when a deposit and a deregistration race in
the same batch.  The premise is symmetric to (and complements) the
existing pre-batch SUBUTXO/UTXO check.

Update `Ledger/Properties/Computational.lagda.md` for the new premise,
and pass `UTxOStateOf s₁` explicitly to `computeUtxow` in the LEDGER
valid branch (the previous `_` resolved by chained unification through
the LEDGER-V constructor, which was fragile and obscured intent).

TODO: fix `Ledger/Properties/Computational.lagda.md`; it's choking on
the new premise.

Every compiler after ghc-8.6, automaticallt derives this typeclass
for every data type. In ghc-9.14 derived Typeable instances result
in warnings.

* Remove un-needed imports.
* Fix deprecation warnings.
* Remove redundant constraints.