Cardano Updates

Also added:
* `JSONField NoExtraFlags`
* `ToJSON NoExtraFlags`
* `ToJSON NoExtraDebugState`
instances to `ouroboros-network:orphaned-instances`.

Moved `NoExtraConfig`, `NoExtraAPI`, `NoExtraChurnArgs` from `dmq-node`
to `ourouboros-network`.

A 25-node smoke cluster at p=0.1 RB generation accumulated 62
"peer command channel full" disconnects over ~16 minutes, with
lagging nodes ~100s behind the leaders.  Tip distribution fragmented
into 8 chains spanning 9 blocks even though all nodes shared
ancestry — not a partition, just receive-side starvation.

Root cause: each peer task has small sub-channels feeding the
client protocol sub-tasks (fetch=16, peer_share=4, tx_submit=16,
cs_reintersect=4, leios_fetch=16).  The shared command-dispatch
loop uses `.send().await` on each, so when any sub-channel fills,
the dispatch loop blocks.  While blocked, no commands move from
the per-peer `commands` channel (cap 4096) — which then fills under
high `ProvideTxs` traffic and trips the coordinator's "command
channel full" disconnect via try_send.  Healthy peers were being
torn down for downstream slowness.

The `ProvideTxs { txs: Vec<…> }` path unspools one tx per
`.send().await`, so a single 30-tx batch already consumed nearly
twice tx_submit's capacity.

Fix:

- Bump sub-channel caps to match expected burst sizes: fetch and
  leios_fetch to 256, tx_submit to 1024, the small signal channels
  (peer_share, cs_reintersect) to 16.  Applied symmetrically in
  peer_task.rs and duplex_task.rs.
- Switch `tx_submit` from `.send().await` to `try_send` with a
  drop-and-warn on Full.  Tx propagation is best-effort gossip —
  another peer will re-broadcast — so dropping is preferable to
  stalling the dispatch loop and tearing down the connection.
  Fetches (FetchBlocks, FetchLeios*) keep `.send().await` since
  those are correctness-critical.

Verified live: rebuilt cluster at p=0.1 holds a single tip across
all 25 nodes with zero "command channel full" disconnects through
block 30 of the new run.

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

* Add FromJSON (TxOut era) as EraTxOut superclass constraint
* Add FromJSON t as Val t superclass constraint
* Add ToJSON/FromJSON for Datum era
* Add FromJSON for ShelleyTxOut, AlonzoTxOut, BabbageTxOut
* Add FromJSON for MaryValue; fix FromJSON/FromJSONKey for AssetName to hex-decode
* Add round-trip JSON property test for TxOut era

CIP-0164 Linear Leios specifies that the cert in an RB endorses the EB
announced by the immediately preceding RB.  sim-rs's `linear_leios.rs`
implements it that way: `latest_rb_id()` → `ebs_by_rb.get(rb_id)` →
quorum + pipeline-timing check → `Some(Endorsement)` or `None`.

shared-consensus instead exposed `has_certified_eb()` /
`certified_eb_slot()` — global queries across the elections map that
returned whichever quorum-reached EB happened to be in CertEligible
right now.  Under high RB generation rates this produced ~100%
endorsement: every RB found *some* older EB in the 10-slot CertEligible
window and attached its cert, regardless of whether that EB belonged
to the parent RB.

Fix:

- New `ChainTree::announced_eb_hash_by(rb_hash)`.  Already stored on
  every `ChainNode`; just needed an accessor.
- New `Elections::eb_certifiable_slot(eb_hash) -> Option<u64>` —
  returns the announced slot iff *that specific* election is at
  quorum and in CertEligible.  Replaces both `has_certified_eb()`
  and `certified_eb_slot()`, which are gone.
- New `LeiosState::eb_certifiable_slot(eb_hash)` delegate.
- New `Consensus::cert_for_parent()` on the net-node facade:
  composes `praos.adopted_tip_announced_eb()` and
  `leios.eb_certifiable_slot()` so the producer can ask, "is the
  parent RB's EB certifiable?" in one call.
- `main.rs` producer uses `cert_for_parent()` instead of the two
  retired methods.

Verified live: at rb_generation_probability=0.25 (mean gap ≈4 slots,
well below the 13-slot CertEligible floor), the rebuilt cluster
produces zero certs — correct under this rule, parent's EB never
matures in time.  At p=0.1 (mean gap ≈10 slots), certs appear when
the inter-RB gap exceeds 13 and not otherwise — observed live as
gaps 1→2 and 3→4 (long) producing certs, gap 2→3 (short) not.

Tests updated: `eb_certifiable_slot_targets_specific_hash` in
net-node's leios facade exercises a per-hash lookup with two
elections at different stages; the elections.rs unit test asserts
the new accessor on a single hash and that unrelated hashes return
None.  Old `certified_eb_slot_returns_latest_quorum_election`
deleted (it asserted the wrong protocol semantics).

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

- Restore datum field in friendly TxOut output (was inadvertently dropped
  in the Exp.TxOut migration); render via ledger datumTxOutL.
- Drop redundant shelleyBasedEraConstraints wraps where pattern-matching
  on IncompleteTxBody already brings the constraint into scope.
- Hoist liftIO out of the do-block in runTransactionSubmitCmd's success
  branch.
- Use mapAndUnzipM in runCompatibleTransactionCmd for clarity.
- Add blank lines between typed let-binding pairs in the min-fee
  calculator for readability.

The IsShelleyBasedEra -> ShelleyBasedEra constraint simplification on
IncompleteTxBody is intentionally not applied; removing the typeclass
forces shelleyBasedEraConstraints wrapping at every call site, which is
the convenience trade-off palas himself flagged.

* Add ToJSON, FromJSON and NFData as EraTxWits superclass constraints
* Add ToJSON/FromJSON for WitVKey, BootstrapWitness
* Add ToJSONKey/FromJSONKey for AccountId
* Add ToJSON/FromJSON for Inclusive and Exclusive
* Add FromJSON for TxIn; fix txInToText to use unTxIx
* Add FromJSON for PoolCert
* Add ToJSON/FromJSON for ShelleyTxWits era
* Add FromJSON for AsIx, AlonzoPlutusPurpose AsIx, TxDats, Redeemers, AlonzoTxWits
* Add FromJSON for ConwayDelegCert, ConwayGovCert, ConwayTxCert era, ConwayPlutusPurpose
* Add FromJSON for GovActionId, Voter, Vote, VotingProcedure, ProposalProcedure, GovAction, GovPurposeId
* Add ToJSON/FromJSON for AccountBalanceInterval, DijkstraScript
* Add FromJSON for DijkstraDelegCert, DijkstraTxCert era
* Add round-trip JSON property test for TxWits era

- Integrated functions to extract and filter blocked UTxOs from pending transactions, improving the robustness of proxy transaction processing.
- Updated `MeshProxyContract` to utilize blocked UTxO references when selecting UTxOs for spending, ensuring only available UTxOs are used.
- Enhanced `ProxyControl` component to manage blocked UTxOs and ensure proper handling of available UTxOs for transactions.
- Refactored UTxO selection logic to improve clarity and maintainability in the proxy transaction workflow.

remove `mu2` from PoP, following IETF draft

Signed-off-by: Chris Gianelloni <[email protected]>