Cardano Updates

The d3e3a89 run still hit Always:zero-exit on
stub/parallel_driver_asteria_player.sh — the failing example shows
fault_injector applied node/stop to asteria-game (max_duration
6.92s) while two driver scripts were running inside, and they
inherited signal-induced exit codes:

  3680.770  FAULT stop node target=[asteria-game] dur=6.92
  3680.813  cleanup asteria-game
  3692.112  anytime_asteria_admin_singleton.sh rc=137  (SIGKILL)
  3692.139  parallel_driver_asteria_player.sh   rc=255  (aborted)

Same root mechanism as the eventually_alive cold-start bug: a
container-stop fault races a script running inside the container,
just on the front side instead of the back side.

Add sdk_run_signal_safe to helper_sdk.sh — runs a binary, absorbs
129/137/143/124/255 into an sdk_unreachable signal + exit 0,
propagates everything else unchanged. Apply it to the four
driver scripts that previously used `exec /bin/<binary>`:
parallel_driver_asteria_player, anytime_asteria_admin_singleton,
serial_driver_asteria_bootstrap, finally_asteria_consistency.

Real binary errors (any non-zero exit outside the signal set) still
fail the script as before.

The legacy iterator-fallback in BlockByHashTxn ran a full block-blob
prefix scan on every hash-index miss, dominating fork-resolution CPU
during preview catch-up (11.2% cum, 370 MB/min churn — issue #2105).

Hash-index entries are written for every block since #1915, so a miss
on a healthy DB means the hash is unknown to us. Returning
ErrBlockNotFound directly lets findPeerForkPath rotate to the next peer
without a worst-case scan. Real backend errors are still surfaced.

Add atomic hit/miss counters (BlockByHashStats) so operators can track
the false-fallback rate and decide whether a pre-#1915 index back-fill
is needed — exactly the metric the issue asks for.

Signed-off-by: SAY-5 <[email protected]>

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

Signed-off-by: Eric Torreborre <[email protected]>

newChannelSubscriber allocated EventQueueSize (100k) slots per
subscriber, dominating the steady-state heap (~190 subscribers, ~192
MB / 45% of in-use heap on a serving preview node). The 100k buffer
was sized for the worst-case bulk-sync burst from #1556 / #1914 but
stayed allocated for the lifetime of every subscription, including
quiescent peergov, governance, and housekeeping callbacks.

Subscribe / SubscribeFunc now default to DefaultSubscriberBuffer
(1024) and new SubscribeWithBuffer / SubscribeFuncWithBuffer variants
let callers opt into a larger size. The bursty consumers in
ledger/state.go (chainsync, blockfetch, chain-update) and the
mempool's chain-update consumer opt into EventQueueSize so the
catch-up burst headroom that motivated #1914 is preserved exactly
where it is needed.

Fixes #2106.

Signed-off-by: SAY-5 <[email protected]>

JWT.verify did not validate the nbf (not before) claim, so JWTs with nbf in the future were incorrectly considered valid. This is a security issue per RFC 7519 Section 4.1.5.

Added an explicit nbf check after JWT decode: if nbf is present and the current time is before it, verify() returns false. JWTs without an nbf claim keep the previous behavior (no nbf enforced).

This is a sister fix to #489/#550 (which addressed the exp claim).

Closes #551

Signed-off-by: Seydi Charyyev <[email protected]>