Cardano Updates

* plan modules: expose `identifier.unit-id` and `package-ids-by-name`

Pure additions for consumers that need to look up packages by
plan-id rather than canonical name.

* `package.identifier.unit-id` (modules/package.nix): a new
  optional field carrying plan.json's per-entry `id` (defaults to
  null when not derived from a plan entry).
* `modules/install-plan/planned.nix`: when constructing the
  per-plan-id package entries, populate `package.identifier`
  with `name` / `version` / `unit-id`.  Without this,
  reading `package.identifier.{name,version}` on a plan-id-keyed
  entry threw — the canonical-name-keyed entry already gets a
  real identifier via `load-cabal-plan.nix`, but the per-plan-id
  ones (used when one canonical name has multiple plan instances)
  did not.
* `package-ids-by-name` (modules/plan.nix +
  install-plan/override-package-by-name.nix): a name → [id]
  index over `plan-json.install-plan`.  A canonical pkg-name can
  appear under several plan ids (per-instance UnitIDs that differ
  only in their dep UnitIDs, or a multi-component package split
  across per-component entries); consumers can now iterate the
  ids unambiguously instead of name-matching against
  `config.packages`.

* plan modules: expose `plan-json-by-id`

Index `config.plan-json.install-plan` by its per-entry `id` so
consumers can look up a single plan entry with one attrset
lookup instead of a linear scan over the install-plan list.
The keys are haskell.nix's per-instance UnitIDs; the values are
the corresponding plan-json entries.

Computed once in
`modules/install-plan/override-package-by-name.nix` (alongside
`package-ids-by-name`) and exposed via the new
`config.plan-json-by-id` option on `modules/plan.nix`.

Index `config.plan-json.install-plan` by its per-entry `id` so
consumers can look up a single plan entry with one attrset
lookup instead of a linear scan over the install-plan list.
The keys are haskell.nix's per-instance UnitIDs; the values are
the corresponding plan-json entries.

Computed once in
`modules/install-plan/override-package-by-name.nix` (alongside
`package-ids-by-name`) and exposed via the new
`config.plan-json-by-id` option on `modules/plan.nix`.

Integrate `StAnnTx` in rules  across all eras

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]>