Cardano Updates

Signed-off-by: Akhil Repala <[email protected]>

The info banner sat inside the genesis() function body, so it fired once per `wb genesis <op>` dispatch

* feat: migrated adder-library-starter-kit code

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

* feat: migrated adder-library-starter-kit code

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

* feat: migrated adder-library-starter-kit code

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

---------

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

* fix(ledger): remove and refund orphaned governance actions after enactment

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

* fix(ledger): add index and update database readme

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

---------

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

The unit tests are not needed anymore

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

* fix: Fixed nilaway nil-safety findings

Signed-off-by: Akhil Repala <[email protected]>

* fix: Fixed the added nilawasy workflow part

Signed-off-by: Akhil Repala <[email protected]>

* fix: removed the nilaway check part form lint workflow

Signed-off-by: Akhil Repala <[email protected]>

* fix: fixed the bot comments

Signed-off-by: Akhil Repala <[email protected]>

---------

Signed-off-by: Akhil Repala <[email protected]>

This is hardening, not recovery. PR #1016 made a pool whose snapshot lags the
current epoch surface at RUPD instead of panicking obscurely. This adds two
fail-loud guards so the same class of corruption is caught earlier and a
half-finished boundary can't silently double-apply. It does NOT implement true
shard resume, and it does NOT repair an already-lagging pool — those remain
open (see #1018 and the restored "TODO: implement true shard resume" notes).

Piece A — guard the silent-corruption hole. `MintedBlocksInc::apply`
accumulates the block count into the pool's positional `live` snapshot slot,
which only holds this epoch's blocks when the snapshot is aligned. A lagging
pool would silently fold later-epoch blocks into a mislabeled slot, corrupting
the `blocks_minted` reward input. `apply` now asserts the snapshot is aligned
to the block's epoch, failing at the origin (block processing) rather than as a
downstream RUPD failure. It sits in the infallible delta-apply layer alongside
its existing invariant `expect`s, so it is a descriptive panic. The block epoch
rides on a transient `#[serde(skip)]` field; WAL-stored deltas are only ever
undone (never re-applied), so the WAL format is unchanged.

Piece B — guard ESTART finalize. `commit_finalize` now asserts every shard
committed and the epoch has not advanced before rotating pools / advancing the
epoch, returning BrokenInvariant::EpochBoundaryIncomplete otherwise — a
defensive assertion that turns a would-be silent double-rotation into a loud
error. It guards the finalize step only; it does NOT make the per-shard
`AccountTransition` replay idempotent.

Error codes + troubleshooting. The two errors are codified (LEDGER-001 pool
snapshot lagging, LEDGER-002 epoch boundary incomplete) with concise messages;
the explanatory prose and operator guidance live in a new
docs/content/operations/troubleshooting.mdx page.

Out of scope: making boundary resume idempotent (the real fix, tracked in
#1018), and rebuilding an already-corrupted pool snapshot window from the
archive. A node that already persisted a lag keeps failing loud with LEDGER-001
and needs a re-bootstrap.

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

This is hardening, not recovery. PR #1016 made a pool whose snapshot lags the
current epoch surface at RUPD instead of panicking obscurely. This adds two
fail-loud guards so the same class of corruption is caught earlier and a
half-finished boundary can't silently double-apply. It does NOT implement true
shard resume, and it does NOT repair an already-lagging pool — those remain
open (see #1018 and the restored "TODO: implement true shard resume" notes).

Piece A — guard the silent-corruption hole. `MintedBlocksInc::apply`
accumulates the block count into the pool's positional `live` snapshot slot,
which only holds this epoch's blocks when the snapshot is aligned. A lagging
pool would silently fold later-epoch blocks into a mislabeled slot, corrupting
the `blocks_minted` reward input. `apply` now asserts the snapshot is aligned
to the block's epoch, failing at the origin (block processing) rather than as a
downstream RUPD failure. It sits in the infallible delta-apply layer alongside
its existing invariant `expect`s, so it is a descriptive panic. The block epoch
rides on a transient `#[serde(skip)]` field; WAL-stored deltas are only ever
undone (never re-applied), so the WAL format is unchanged.

Piece B — guard ESTART finalize. `commit_finalize` now asserts every shard
committed and the epoch has not advanced before rotating pools / advancing the
epoch, returning BrokenInvariant::EpochBoundaryIncomplete otherwise — a
defensive assertion that turns a would-be silent double-rotation into a loud
error. It guards the finalize step only; it does NOT make the per-shard
`AccountTransition` replay idempotent.

Error codes + troubleshooting. The two errors are codified (LEDGER-001 pool
snapshot lagging, LEDGER-002 epoch boundary incomplete) with concise messages;
the explanatory prose and operator guidance live in a new
docs/content/operations/troubleshooting.mdx page.

Out of scope: making boundary resume idempotent (the real fix, tracked in
#1018), and rebuilding an already-corrupted pool snapshot window from the
archive. A node that already persisted a lag keeps failing loud with LEDGER-001
and needs a re-bootstrap.

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

Signed-off-by: Akhil Repala <[email protected]>

Bumps [markdown-it](https://github.com/markdown-it/markdown-it) from 14.1.1 to 14.2.0.
- [Changelog](https://github.com/markdown-it/markdown-it/blob/master/CHANGELOG.md)
- [Commits](https://github.com/markdown-it/markdown-it/compare/14.1.1...14.2.0)

---
updated-dependencies:
- dependency-name: markdown-it
  dependency-version: 14.2.0
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <[email protected]>

Signed-off-by: Akhil Repala <[email protected]>

The info banner sat inside the genesis() function body, so it fired once per `wb genesis <op>` dispatch

Signed-off-by: Akhil Repala <[email protected]>