Cardano Updates

The build-time cabal.project pulled version pins from too many places:
a slice's whole `transitive-deps` closure (an over-broad bare `==<ver>`
pin added to cover test/bench components) plus build-tool `exe-depends`
lib closures.  When a boot library is reinstalled at the *same* version
(e.g. `text-2.1.4` boot `-inplace` vs a reinstalled `txt-2.1.4-<hash>`),
a bare `text ==2.1.4` pin can't disambiguate the two units, so cabal
splits lib deps between them and every dependent UnitId drifts
(`checkAgainstPlan` fails for js-template-haskell on ghcjs / wasm / the
profiled native variants).

Treat each dependency kind distinctly at build time:

  * depends      -> source (repo) + `<dep> ==<ver>, <dep> source`
  * setup-depends-> source (repo) + `<pkg>:setup.<dep> ==<ver>`
  * exe-depends  -> source only (no constraints)

Constraints now come only from the *complete* library-`depends` closure
(`dependsSlices` = directDepSlices ++ home library deps ++ the package's
own library for non-lib components) and per-package setup-constraints.
The `source` qualifier on every reinstalled lib forces cabal off the
GHC-bundled `-inplace` unit even when versions match.  Source + the six
per-package block groups keep riding the existing `transitive-deps`
closure (already free of pkgsBuildBuild tool slices after the previous
commit).

Removed: the blkFrags whole-closure version pin and the exe-depends
contribution to the constraints scope.  Skip the self pkg-name when
emitting extra-packages/constraints (its own library can now enter the
depends walk via `ownLibSlice`; also listing the local target as a repo
package triggers cabal's target-matcher ambiguity, Cabal-7130).

Verified green: native + ghcjs js-template-haskell.check and the
aarch64-android iserv-proxy-interpreter.

Co-authored-by: olgahryniuk <[email protected]>

Node config and script for the Leios testnet

A full mainnet sync to tip (~317k handles, ~14.7M ada_handle_history_item
rows) exhausted the 2g heap with recurring OutOfMemoryError, wedging the
HTTP server while the indexer thread limped on. 4g runs comfortably
(steady-state heap ~650MB) and the REST API stays responsive at tip.

Surfaced by the mainnet full-sync integration-test harness.

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

Also re-organize flake inputs to be more clear which is used for what.

A passive follower could wedge permanently once at the live tip: after a
deep rollback the peer re-announces its chain, but our cached copy has a
gap (the peer fragment skipped a header, and that gap block was never
fetched because it never appeared in `missing` — it isn't in the
fragment).  `select_chain` then classified the strictly-better candidate
as a non-contiguous / fork-mismatch orphan, cleared the fragment, and
requested re-intersection — which the peer answers by rolling back to our
tip and re-announcing, looping ~1.4x/s with the tip frozen.

Primary fix (gap-fill): when a strictly-better candidate's cached chain
is non-contiguous, fetch the contiguous range [common ancestor ->
candidate tip] from the announcing peer instead of giving up.  A range
request needs only the two endpoints; the peer streams every intermediate
block, healing the gap so a later pass switches.  Genesis-rooted
ancestors still fall back to the orphan verdict (can't anchor a range at
Origin).

Secondary safety net (fork-tip prune): the periodic gap-bridge could also
fixate on an abandoned fork tip left far ahead in chain_tree after the
rollback — no connected peer offers it, so the bridge re-issued a peerless
(peer_count=0) no-op fetch forever.  `ChainTree::remove_fork_tip` drops
such an unreachable best_tip and recomputes best_tip; retry_select_chain
prunes rather than emit a peerless fetch.

Tests: select_chain_heals_noncontiguous_cached_candidate_via_range_fetch
and retry_prunes_unreachable_best_tip_instead_of_peerless_fetch (both
verified to fail without the respective change).  300 pass.

Co-Authored-By: Claude Opus 4.8 <[email protected]>

Fix order of arguments in user guide example