Cardano Updates

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

In `conwayGovTransition`, we remove the condition on
`hardforkConwayBootstrapPhase` for checking `ZeroTreasuryWithdrawals`.

We then replayed the preview, preprod and mainnet public chains with
this change which guarentees there were no empty treasury withdrawals
pre-Conway era.

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

Pulls in the depth checklist (cluster_fork_depth_N_observed) and
adversary_observed_as_peer Sometimes assertions onto the
cardano_node_adversary testnet.

Two new probes on top of the existing fork-tree state machine.

Layer 3 — depth checklist
  - Tracks maxForkDepth in tracer-sidecar State.
  - Emits one Sometimes assertion per depth threshold from 2 up to
    k - 1: cluster_fork_depth_2_observed, _3_observed, ... _k-1.
  - Reading the report, the highest passed threshold tells you how
    deep the cluster forked under fault injection without drilling
    into per-event details.

Layer 2 — peer-observability probe
  - Adds adversary_observed_as_peer Sometimes assertion.
  - Fires on the first Net.InboundGovernor.* log line whose JSON
    contains the substring "adversary.example", proving the
    adversary's chain-sync sessions reached a producer's peer-
    selection layer at least once during the run (not just the
    kernel TCP backlog).
  - Uses a substring check against the encoded JSON, so we don't
    pin the message schema — the producer's tracer can rename
    fields without breaking the probe.

State now carries maxForkDepth and adversaryObservedAsPeer; both
land alongside the existing forkObserved / forkExceededK flags
inside updateForkTree's refresh function and a new generic
mkSpec rule.

- Add module-level documentation to FindDIDSigningKeys explaining:
  * DID verification relationships concept
  * ISSUING_KEY ↔ assertionMethod mapping (for credential issuance)
  * AUTHENTICATION_KEY ↔ authentication mapping (for DID ownership proofs)
  * Why multiple keys exist (key rotation, security, scalability)
  * Reference to W3C DID Core Specification

- Enhance CreateJwt documentation:
  * Explain SSI JWT use cases
  * Clarify why ISSUING_KEY is default for credential issuance
  * Document when to use AUTHENTICATION_KEY for authentication flows
  * Add complete JSDoc parameter descriptions

- Add CreateSDJWT documentation:
  * Explain Selective Disclosure JWT (SD-JWT) concept
  * Document privacy-preserving credential sharing use case
  * Reference RFC 9052 specification
  * Explain verification process

- Add matchKeys() documentation:
  * Explain key matching algorithm
  * Clarify multibase and JWK encoding support
  * Ensure keys are authorized for requested purpose

Addresses issue #598: Makes it easier for new contributors to understand
DID verification relationships, key purposes, and SSI concepts.

Signed-off-by: Anshika Chaubey <[email protected]>

Signed-off-by: Yummy-Yums <[email protected]>

Signed-off-by: Yummy-Yums <[email protected]>

(cherry picked from commit 6fe8f3c571d7dc413cfa9aebc6fbc64b83bd8e76)

(cherry picked from commit 2fe41f902e7fff7083ecbc6ff2c8f1e3b7478126)

(cherry picked from commit db7f0ad067c9db36b4d23f14395e158ae0c1a79c)

(cherry picked from commit 805165ebe9657c271eda46f39c7bc52da69568cc)

(cherry picked from commit f0f7eadca9869a0571da14c624b7f5386af692c9)

(cherry picked from commit 547863a5fc723ed669462354368af7ffc433a7a2)

(cherry picked from commit c88386801cc002ff037d7d5eceee0e4f657fde3b)