Cardano Updates

Support ghc 9.14

cardano-node 10.6.2 changed the log `host` field from
"p6.example" to just "p6" (hostname without domain). The
tracer-sidecar used `fromJust (stripSuffix ".example" host)`
which crashes on the new format. Use `fromMaybe` instead to
handle both formats.

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

# Description

The ContT experiment showed some improvements that could be made for
clarity on both ChainSelection and the LedgerDB. The Changelog fragment
describes each cleanup.

wb | enable deployment of local commits

* Propagate writeShellApplication runtimeInputs via propagatedNativeBuildInputs

The switch from nix-print-dev-env to devShellTools (a354771) broke
runtimeInputs visibility in -env container scripts. writeShellApplication
embeds runtimeInputs in the wrapper's own PATH, but $stdenv/setup (which
the -env scripts source) only walks buildInputs/nativeBuildInputs — not
the internal PATH of wrappers within those inputs.

The previous fix (76d6b37) added curl explicitly to buildInputs, but
this is fragile: any future runtimeInputs change requires a parallel
edit in the shell's input lists.

Instead, use propagatedNativeBuildInputs on the wrapper derivation.
When $stdenv/setup processes wrapped-cabal from nativeBuildInputs, it
transitively follows propagatedNativeBuildInputs and adds curl (and
cabal-install) to PATH for the whole environment. This is the standard
Nix mechanism for transitive dependency propagation.

Applies to all four shell definitions: dynamic, static, cross-js,
cross-windows. Removes the explicit curl additions from 76d6b37.

* Extract writeShellApplicationWithRuntime helper to writers.nix

Refactor the inline .overrideAttrs pattern (used to propagate
writeShellApplication's runtimeInputs via propagatedNativeBuildInputs)
into a shared helper function with extensive documentation explaining
why this is needed.

The core issue: devx generates -env container scripts using devShellTools,
which reconstructs the environment via $stdenv/setup's findInputs.
findInputs walks propagatedNativeBuildInputs metadata files but does NOT
look inside writeShellApplication wrapper scripts. Without propagation,
runtimeInputs (e.g. curl for HTTPS hackage transport) are invisible to
the container environment.

See writers.nix for the full architectural explanation.

Refactor the inline .overrideAttrs pattern (used to propagate
writeShellApplication's runtimeInputs via propagatedNativeBuildInputs)
into a shared helper function with extensive documentation explaining
why this is needed.

The core issue: devx generates -env container scripts using devShellTools,
which reconstructs the environment via $stdenv/setup's findInputs.
findInputs walks propagatedNativeBuildInputs metadata files but does NOT
look inside writeShellApplication wrapper scripts. Without propagation,
runtimeInputs (e.g. curl for HTTPS hackage transport) are invisible to
the container environment.

See writers.nix for the full architectural explanation.

The switch from nix-print-dev-env to devShellTools (a354771) broke
runtimeInputs visibility in -env container scripts. writeShellApplication
embeds runtimeInputs in the wrapper's own PATH, but $stdenv/setup (which
the -env scripts source) only walks buildInputs/nativeBuildInputs — not
the internal PATH of wrappers within those inputs.

The previous fix (76d6b37) added curl explicitly to buildInputs, but
this is fragile: any future runtimeInputs change requires a parallel
edit in the shell's input lists.

Instead, use propagatedNativeBuildInputs on the wrapper derivation.
When $stdenv/setup processes wrapped-cabal from nativeBuildInputs, it
transitively follows propagatedNativeBuildInputs and adds curl (and
cabal-install) to PATH for the whole environment. This is the standard
Nix mechanism for transitive dependency propagation.

Applies to all four shell definitions: dynamic, static, cross-js,
cross-windows. Removes the explicit curl additions from 76d6b37.

The switch from nix-print-dev-env to devShellTools (a354771) broke
runtimeInputs visibility in -env container scripts. writeShellApplication
embeds runtimeInputs in the wrapper's own PATH, but $stdenv/setup (which
the -env scripts source) only walks buildInputs/nativeBuildInputs — not
the internal PATH of wrappers within those inputs.

The previous fix (76d6b37) added curl explicitly to buildInputs, but
this is fragile: any future runtimeInputs change requires a parallel
edit in the shell's input lists.

Instead, use propagatedNativeBuildInputs on the wrapper derivation.
When $stdenv/setup processes wrapped-cabal from nativeBuildInputs, it
transitively follows propagatedNativeBuildInputs and adds curl (and
cabal-install) to PATH for the whole environment. This is the standard
Nix mechanism for transitive dependency propagation.

Applies to all four shell definitions: dynamic, static, cross-js,
cross-windows. Removes the explicit curl additions from 76d6b37.

* Update workflow step name for prefix-less check-runs

The hydra-github-bridge no longer prefixes check-run names with
"ci/hydra-build:" for zw3rk CI. Update the step name to match.
The JQ filters and wait-for-hydra action (check: required) now
work correctly with the bare job names.

* Update head.hackage FOD hash

The head.hackage index is a rolling target — upstream published new
packages, invalidating the previous hash.

  specified: sha256-nFFut7+8NzUps+4MsmnAo2bLp1EE2Dx4eWqTeZ2aYqI=
  got:       sha256-P0hOiQyh54Y5Pyl9rjpEE5Er/u83aeXIKBygzniRZtk=

* Add curl to shell buildInputs for HTTPS transport

The wrapped-cabal writeShellApplication includes curl as a
runtimeInput, but that only puts curl on PATH when the wrapper
script itself runs. In the -env container scripts (which source
$stdenv/setup to construct PATH from buildInputs/nativeBuildInputs),
curl is NOT on PATH for other programs.

This breaks GHC CI builds: GHC's Makefile bootstraps its own
stage0 cabal (debug build, no native TLS) which then needs curl
on PATH to download packages from Hackage over HTTPS. Without
curl available, it fails with Cabal-7113.

Fix: add curl directly to buildInputs/nativeBuildInputs in
dynamic.nix, static.nix, and cross-js.nix so it's always
available on PATH regardless of how the environment is sourced.

The wrapped-cabal writeShellApplication includes curl as a
runtimeInput, but that only puts curl on PATH when the wrapper
script itself runs. In the -env container scripts (which source
$stdenv/setup to construct PATH from buildInputs/nativeBuildInputs),
curl is NOT on PATH for other programs.

This breaks GHC CI builds: GHC's Makefile bootstraps its own
stage0 cabal (debug build, no native TLS) which then needs curl
on PATH to download packages from Hackage over HTTPS. Without
curl available, it fails with Cabal-7113.

Fix: add curl directly to buildInputs/nativeBuildInputs in
dynamic.nix, static.nix, and cross-js.nix so it's always
available on PATH regardless of how the environment is sourced.