Cardano Updates

Freeze the current (unhelpful) error output for three forms of invalid
UPLC identifier:
- `foo-bar`                — hyphen followed by non-digits
- `foo-123-456`            — double `-NNN` suffix
- `pubKeyHash-305478r71`   — hyphen + digits + more letters (the shape
  Scalus 0.16.0's `toUplcOptimized` emits, from issue #7742)

All three cases produce misleading diagnostics today — notably the
Scalus case reports the error 8+ characters past the offending name.
Capturing the status quo as goldens so that a follow-up improvement to
name-parser diagnostics shows up as an explicit golden-file diff.

When the unquoted-identifier parser finishes, require that the next char
is a real word-boundary (not another identifier char and not another
'-'). Otherwise the caller wrote something like `pubKeyHash-305478r71`,
`foo-bar` or `foo-123-456`: the '-NNN' we just consumed as the numeric
unique-suffix is not actually terminal, and the prefix interpretation
would silently mis-parse. Consume the remainder of the extended
identifier so the diagnostic can cite the full bad text, then raise a
new `InvalidIdentifier` custom parser error with a caret on the start
of the identifier and an actionable hint to quote it with backticks.

For the original Scalus 0.16.0 HTLC reproducer this changes the error
from `htlc.uplc:448:39: unexpected '(' expecting ')'` (on a lambda 8+
chars past the real site) to `htlc.uplc:447:41: Invalid identifier
'pubKeyHash-305478r71'` — on the offending name itself.

The three negative goldens added in the previous commit are updated to
the new message; all 3886 tests across plutus-core/untyped-plutus-core/
plutus-ir pass unchanged.

Bumps [webiny/action-conventional-commits](https://github.com/webiny/action-conventional-commits) from 1.3.1 to 1.4.2.
- [Release notes](https://github.com/webiny/action-conventional-commits/releases)
- [Commits](https://github.com/webiny/action-conventional-commits/compare/faccb24fc2550dd15c0390d944379d2d8ed9690e...7f91b1595ca1951cdb671ddc9f07a49081ec5b69)

---
updated-dependencies:
- dependency-name: webiny/action-conventional-commits
  dependency-version: 1.4.2
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

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

Resolves https://github.com/input-output-hk/ouroboros-leios/issues/837

DONE
- [x] Move the EB announcement from the Ledger Block to the Praos Header
- [x] Add `EbAnnouncement` type that holds an `EbHash` and its size!
     - [x] Remove the `certifies` field
  - [x] Move the LeiosState from the Ledger to the ChainDepState
- [x] Adds 'cummulative' EB size tracking in the state (TODO: Grafana
this)
  - [ ] ~~Move the Certificate from the Ledger into Consensus~~
- Ugh for now I'm keeping it in the Ledger because it's easier, albeit
not ideal
   - [x] Update to Ledger with backward compatible Block codec
   - [x] Introduces `ForgeBlockArgs` for my own sanity
- [x] FIX: [EB only diffused if announced in
forge](https://github.com/IntersectMBO/ouroboros-consensus/pull/1978/commits/85aafd4146617fea79f825d989bf1ca5b9dfb6b6)
 
NOTES
- `ResolveLeiosBlock` machinery is a hack that works! We're blindly
guessing that `blk` might contain something that can be resolved like a
LeiosCertificate and it returns a `blk` that hopefully has a fully
resolved `blk` that can be applied. Imo a morally correct approach would
to have `data RankingBlock blk = LedgerRb blk | CertRb LeiosCertificate`
which we can use to make such distinction and manage the resolution
process here and elsewhere in the abstract code base where that
distinction matters (like the ForgeLoop)
- `applyBlock` currently does `resolveLeiosBlock` and then
`tickAndReapply` which is not incorrect as in the case of there being a
Leios Cert, we need to base changes from the associated EB on top of the
`prev` Ledger State (I think that means we shouldn't tick?)
  - see https://github.com/input-output-hk/ouroboros-leios/issues/857
- Apropos `tx-centrifuge` it doesn't seem like there's any way around
breaking the API `BlockFetch`. For the current pragmatic solutions we
hide the `Certificate` behind the `blk` and therefore `BlockFetch` will
happily return you a Certificate which will break `tx-centrifuge`. That
being said, `ChainSync` is also necessarily having a breaking change
since we added new fields to the PraosHeader.

Bumps [github.com/blinklabs-io/plutigo](https://github.com/blinklabs-io/plutigo) from 0.1.8 to 0.1.9.
- [Release notes](https://github.com/blinklabs-io/plutigo/releases)
- [Changelog](https://github.com/blinklabs-io/plutigo/blob/main/RELEASE_NOTES.md)
- [Commits](https://github.com/blinklabs-io/plutigo/compare/v0.1.8...v0.1.9)

---
updated-dependencies:
- dependency-name: github.com/blinklabs-io/plutigo
  dependency-version: 0.1.9
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

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

Bumps [github.com/blinklabs-io/ouroboros-mock](https://github.com/blinklabs-io/ouroboros-mock) from 0.9.1 to 0.10.0.
- [Release notes](https://github.com/blinklabs-io/ouroboros-mock/releases)
- [Commits](https://github.com/blinklabs-io/ouroboros-mock/compare/v0.9.1...v0.10.0)

---
updated-dependencies:
- dependency-name: github.com/blinklabs-io/ouroboros-mock
  dependency-version: 0.10.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

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

Suggestions for CIP-179

BEGIN IMMEDIATE results in directly locking the transaction for write
access, while BEGIN does defer it to the first write statement. Thus, if
we never do a write, the connection does not get blocked by other
connections and reduces lock contention.

The sql query was very inefficient and also the completion tracking
can't afford to check hashes. Keeping a counter in the database, written
to within the same transaction seemed the best way forward.

Docs - Manual Rollbacks

Co-authored-by: Alexey Kuleshevich <[email protected]>

feat(makefile): refactor Makefile with improved targets, venv support, and help

Unblocks scheduled runs. asteria-player:dev never published —
publish-images skips it ("Tag 'dev' not found in repo"), so
Antithesis fails to pull and every scheduled run since 2026-04-25
came back Incomplete with zero container stdout.

Asteria work continues under #56 / PR #67. Re-add to compose once a
real image tag is published.

Ogmios already absent from main (removed in 7e0f8f5 pending #49).

- Add virtual environment management for all targets
- Organize targets into sections: setup, linting, release, documentation, maintenance, help
- Add clean and clean-all targets for artifact and venv cleanup
- Add install-doc target for documentation dependencies
- Improve documentation build process
- Add self-documenting help target with usage info
- Use consistent variable names and comments

We constrain both, the forged EBs and error out on the fetch client if
an EB bigger than the (hard-coded) limit is seen.

The sql query was very inefficient and also the completion tracking
can't afford to check hashes. Keeping a counter in the database, written
to within the same transaction seemed the best way forward.

Add plain DecCBOR instances for DijkstraBlockBodyRaw and
DijkstraBlockBody (needed for decoder equivalence tests), and a
custom ToExpr instance for DijkstraBlockBody. Add block_body to
the CddlSpec test suite.

Replace the manual segmented-witness serialization with MemoBytes,
which simplifies the code significantly. The block body is now
serialized as a flat 3-element list [invalid_transactions, transactions,
peras_certificate] instead of 5 separate segments.

Also fix PerasCert to encode/decode as bytes (matching CDDL),
reimplement alignedValidFlags using IntSet, and expose
DijkstraBlockBodyRaw/MkDijkstraBlockBody from Internal module.