Cardano Updates

This code path was forgotten and only the volatileDB / forker call site
of applyBlock had the resolution of CertRB -> EB transactions.

The DB integration test suite now runs the groups concurrently:

 * Alonzo-era
 * Babbage-era
 * Conway-era
 * QSM (QuickCheck State Machine)

Concurrent tests cannot share a database, so each group has its own
copy. Grouping at the top level keeps the databases/threads manageable.

Also, add the required databases in the nix `preCheck` hook and GitHub
CI workflows.

The DB integration test suite now runs the groups concurrently:

 * Alonzo-era
 * Babbage-era
 * Conway-era
 * QSM (QuickCheck State Machine)

Concurrent tests cannot share a database, so each group has its own
copy. Grouping at the top level keeps the databases/threads manageable.

Also, add the required databases in the nix `preCheck` hook and GitHub
CI workflows.

Adds tests for internal/config covering defaults, env-var loading, YAML loading and precedence, plus reliability hardening of SaveAtomic (F_FULLFSYNC on darwin, explicit enc.Close, per-path mutex via sync.Map, unique tmp via os.CreateTemp, fsynced parent dir, new SaveAtomicCtx wrapper for cancellation). Fixes a precedence bug where envconfig.Process ran after yaml.Unmarshal so env silently overrode YAML; the order is now env-first / YAML-last per the documented CLI > YAML > env precedence.

BREAKING: deployments that today set an env var to override a YAML key will see the YAML value win after this change.

Closes #708

Signed-off-by: Ales Verbic <[email protected]>

The wasm and JavaScript backends need a small set of dev-time tools
that aren't part of a stock Haskell shell:

  * nodejs_22   — required for utils/jsffi/post-link.mjs (uses
                  import.meta.filename added in Node 20.11; Ubuntu's
                  apt nodejs is 18.x and silently breaks the post-link
                  step) and for JSFFI host execution at test time
  * wabt        — wasm-objdump for inspecting custom sections (e.g.
                  detecting ghc_wasm_jsffi imports) in wasm modules
  * wasmtime    — pure-WASI runtime, when a wasm module has no JSFFI
                  imports and can run standalone
  * emscripten  — the JavaScript backend's C toolchain (emcc / em++ /
                  emar / emnm / emranlib / emstrip)

Currently downstream consumers (e.g. stable-haskell/ghc's wasm
cross-compiler CI) bootstrap these per-platform via apt + NodeSource +
nix-env + curl installers, plus PATH workarounds for devx scrubbing
/usr/bin. Shipping them in the flavor collapses ~70 lines of
platform-shell to one `shell:` line in user workflows.

Deliberately NOT bundled: wasi-sdk. Its version needs to match the
wasm32-wasi-ghc cross-compiler bundle that ghc-wasm-meta
(https://gitlab.haskell.org/ghc/ghc-wasm-meta) owns, so keeping that
pin in ghc-wasm-meta avoids version drift across two trees. Users
still bootstrap wasi-sdk via ghc-wasm-meta for wasm32-wasi builds.

Closure cost on aarch64-darwin (paired with the prior trim commit):

  ghc98-minimal-ghc      (current master) :  6.12 GB
  ghc98-minimal-ghc      (after trim PR)  :  4.00 GB  (-2.12 GB)
  ghc98-minimal-ghc-web  (this commit)    :  5.99 GB  (+1.99 GB)

Net: the web flavor with the full toolchain ends up SMALLER than the
current untrimmed minimal-ghc, because the trim commit removed
ghc-9.10.3 and emscripten's LLVM/apple-sdk now dedupes against the
shell's base nixpkgs pin (no version fragmentation).

Comfortably under the 10 GB GitHub Actions per-repo cache cap on
both Darwin and Linux (Linux delta is similar magnitude — emscripten
+ closure-compiler are the heavy hitters on both).

Verified inside the patched shell:

  $ ghc --version            # 9.8.4
  $ cabal --version          # 3.17.0.0
  $ happy --version          # 2.1.7
  $ alex --version           # 3.5.4.0
  $ git --version            # 2.51.2 (gitMinimal)
  $ node --version           # v22.21.1
  $ wasm-objdump --version   # 1.0.37
  $ wasmtime --version       # 38.0.3
  $ emcc --version           # 4.0.12-git

All on the expected store paths.

The `withGHCTooling` block in dynamic.nix sourced `happy` and `alex`
from nixpkgs's `pkgs.haskellPackages`, which builds them with a
different GHC than the shell's `compiler` (currently ghc-9.10.3 in
nixpkgs vs ghc-9.8.4 in our shell). The Haskell library outputs of
both packages live under `lib/ghc-<other-ver>/lib/*.dylib`; their
.dylib path strings anchor the foreign GHC in the closure via Nix's
reference scanner.

On aarch64-darwin this dragged in ghc-9.10.3 (1.40 GB) and
ghc-9.10.3-doc (753 MB) — ~2.15 GB of essentially-unused payload.

Switch to haskell.nix's `tool` builder (same pattern as cross-js.nix
and cross-windows.nix), which builds happy/alex with the shell's
`compiler-nix-name`. The resulting library outputs reference the GHC
that's already in the closure rather than dragging in a second one.

While here:
* swap `git` → `gitMinimal` — drops the heavyweight perl-modules and
  git-doc that aren't useful inside the dev shell (~150 MB cascade).
* tool-map.nix: drop `inherit cabalProjectLocal` from happy/alex.
  They're standard mainline packages and build cleanly from regular
  hackage; the inherited cabalProjectLocal pinned a head.hackage SHA
  that was stale and broke fresh evaluations of `(tool "happy")` /
  `(tool "alex")`. While there, bump happy 1.20.1.1 → 2.1.7 and
  alex 3.2.7.3 → 3.5.4.0 to match what nixpkgs.haskellPackages was
  shipping previously, so users see no behavioural change.

Measured on aarch64-darwin (ghc98-minimal-ghc):
  before:  6.12 GB / 228 paths
  after :  4.00 GB / 196 paths
  saved :  2.12 GB (34.7% smaller)

Top removed paths:
  ghc-9.10.3              1399 MB
  ghc-9.10.3-doc           753 MB
  git-2.51.2                49 MB
  git-2.51.2-doc            15 MB
  perl5.40.0-SSLeay/Mozilla/IO-Socket-SSL (gitMinimal cascade)

Verified inside the patched shell:
  $ ghc --version    # 9.8.4
  $ cabal --version  # 3.17.0.0
  $ happy --version  # 2.1.7 (same as before)
  $ alex --version   # 3.5.4.0 (same as before)
  $ git --version    # 2.51.2

This test builds cabal-simple via the low-level callCabalProjectToNix /
mkCabalProjectPkgSet path with a minimal modules list, so it doesn't
pull in modules/cabal-project.nix's config — in particular the android
default that adds `package * ghc-options: -optl-static -optl-ldl` so the
exe links statically.  A dynamically-linked Android binary references
/system/bin/linker64 at runtime, which qemu-user can't open on the build
host, so the v2 run-check (which executes the built exe) failed with
`qemu-aarch64: Could not open '/system/bin/linker64'`.  (v1 only passed
because lib/check.nix re-overrides the *check* exe with
setupBuildFlags = -optl-static; v2 runs the pre-built slice exe, so it
needs the flag at the project level.)

Replicate modules/cabal-project.nix's android default in the test, for
both the plan (callCabalProjectToNix) and the build (modules), so the
exe is statically linked and runnable under qemu-user.

Verified: aarch64-android-prebuilt callCabalProjectToNix.run now runs
the exe ('Hello, Haskell!') under v2.

# Conflicts:
#	src/data/apps.js

Prerequisite for running tests concurrently.

All DB tests share the same database, so we can read the from the
`PGPASSFILE` environment variable. When we run them in parallel, this
won't be possible, since each running test will need its own database.

Instead, explicitly pass the `PGConfig` to all tests, which will allow
different database configs per test run.