Cardano Updates

Resolves all clippy warnings under `cargo clippy --all-targets
--all-features` (modulo an external `chumsky` future-incompat note),
covering the lib invocation CI runs (`cargo clippy -- -D warnings`)
and test targets.

Notable changes:
- alonzo phase1 collateral check refactored to share the lovelace
  comparison across `Coin` and `Multiasset`
- script_data tests: `const LazyLock` → `static LazyLock` to satisfy
  the interior-mutability lint
- exposed existing tuple type aliases in tests/common.rs as `pub` and
  used them in babbage.rs / conway.rs in place of inline tuples
- replaced `assert!(false, msg)` with `panic!(msg)` in validate tests
  and pallas-math

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Custom generators and validators attached to a generic Huddle rule can
now look up the type bound to a generic parameter at the enclosing
rule. Add `generateFromGRef` and `validateFromGRef` helpers, plus
`validateFromName`. Custom closures attached to generic rules are
wrapped at monomorphization time to install the active local bindings
into `geLocal`/`veLocal` on `GenEnv`/`ValidateEnv`, which a new
`lookupGRef` method on `MonadCddl` consults.

`runCBORValidator` now takes a `CTreeRoot ValidatorPhase` directly.
`GRef` moves to `Codec.CBOR.Cuddle.CDDL` so lower-level modules can
use it; `Huddle` re-exports it without the constructor.

New Huddle example `tagRangeExample`: `foo<a> = #6.1280(a) / #6.1400(a)`
used at `[foo<uint>, foo<nint>]`, with a custom generator that picks any
tag in `1280..1400` (biased toward the edges via `frequency`) and a
custom validator accepting the same range. Both delegate to the bound
generic type via `generateFromGRef` / `validateFromGRef`.

Wired into the `Generated value validates` round-trip suite, plus a
separate property that classifies tag samples to surface edge
coverage (~38% edge / ~62% middle).

This is obviously a dirty hack, but works to drive the development right
now and side-steps key registration, while already exploring how to pass
the voting key into the right consensus components.

This results in votes being forwarded already. However, this is
obviously not safe to do this way in adversarial settings.

The unticked chain dep state does not get transitioned through
eras (like the ticked state). Thus it is not always availble to the
forgeBlock. It may only change at protocol boundaries, but the HFC is
indexed on eras and we forego matching all of them in exchange of
'Nothing' across an era boundary.

In fact, it may not be a good idea to have an EB be certified across an
era boundary anyways.

Update flake inputs