Add a trancheoffset make variable and a new itest-only-parallel
target that runs tranches without re-building the itest binaries.
Together with the existing tranches and parallel variables, this
allows a single itest configuration to be spread over multiple
machines: each machine runs ITEST_PARALLELISM tranches starting at
its own offset, against the same total tranche count and shuffle
seed.

itest-parallel is unchanged in behavior and is now expressed as
build-itest followed by itest-only-parallel.

The three postgres itest configurations were the longest jobs in the
workflow at 65-81 minutes each: every job built the itest binaries
from scratch and then ran all 8 tranches in parallel on a single
4-core runner.

Following the approach used in lightninglabs/taproot-assets, build
the itest binaries once per distinct build-tag set (plain postgres,
and postgres with test_native_sql) in a dedicated job that uploads
them as artifacts. The test jobs download the binaries and each runs
only SPLIT_ITEST_PARALLELISM (2) of the SMALL_TRANCHES (8) tranches,
spreading every postgres config over 4 runners. The shuffle seed is
fixed per configuration rather than per job so that all tranche
groups of a config agree on the test partition.

Both jobs cost a full runner slot and per-job setup to run a grep on
go.mod and a 20-line shell script respectively. With runner-pool
queueing being the dominant contributor to CI wall time, runner
slots matter more than step duration. Run both as steps of the
static checks job instead, dropping three jobs per run.

The job deleted all caches not accessed within 12 hours on every
pull request from a write-access author. At current activity levels
the caches produced within any 12-hour window already exceed the
10GB repository quota (currently 11GB across 15 entries), so the job
only ever deletes entries that GitHub's LRU eviction would discard
anyway. It also has a harmful failure mode: after any quiet 12-hour
stretch the next PR wipes every cache, including the hot master
branch ones, forcing a fleet-wide cold build. LRU eviction never
does that, since master caches are kept fresh by restore-keys hits
from PR jobs.

Dropping the job also lets the workflow's actions: write permission
fall back to read-only.

The cleanup-space action dates from when hosted runners shipped with
roughly 14GB of free disk. Current ubuntu runners have 145GB disks
with 88GB free before cleanup (measured in run 27379687191), far
more than any job here uses, so the step only adds about two minutes
of latency to the start of every job that carries it - roughly 60
runner-minutes per workflow run across its nine usages. The release
workflow keeps its usage since it runs rarely and off the PR path.

Remove six itest configurations from per-PR CI:

  - bitcoind-sqlite-nativesql and bitcoind-postgres-nativesql: the
    test_native_sql build tag only splices in the dev migrations
    from sqldb/migrations_dev.go, which is empty by design now that
    all migrations live in the main line. The -experiment flavors
    are therefore identical today and remain a strict superset
    whenever a dev migration is in flight, so the plain nativesql
    flavors add no coverage.

  - bitcoind-miner: the miner is the lntest harness's block
    generator; lnd never connects to it, so this config varies no
    production code. Breakage in lntest's bitcoind miner support is
    a test-framework concern, not a per-PR lnd one.

  - bitcoind-notxindex and bitcoind-rpcpolling: each differs from
    the main bitcoind run only in a thin chain-access adapter (the
    txindex-less lookup fallback and the RPC polling client), both
    rarely touched and partially unit-covered, while the rest of the
    run is a duplicate.

  - bitcoind-etcd: niche clustered deployment shape; the etcd
    storage layer itself is still unit-tested on every PR via the
    targeted kvdb_etcd job.

This removes nine runner jobs and roughly 230 runner-minutes per
run, which translates directly to less queueing under the org-level
concurrent-job cap.

The bitcoind interface test variants both ran with a transaction
index available, so the notifier's manual historical lookup paths
(confDetailsManually, historicalSpendDetails) were only exercised
incidentally, via script-dispatch requests and tx-not-found races.
End-to-end coverage of the no-txindex deployment shape came from the
bitcoind-notxindex itest configuration, which was removed from
per-PR CI.

Add a bitcoind-no-txindex variant to the interface suite. It runs
against the same registered bitcoind driver but with txindex
disabled on the backend, forcing every historical confirmation and
spend lookup through the manual scan fallbacks. This covers the
differing surface of the removed itest configuration more
systematically and at far lower cost, since it runs inside the
existing unit test jobs.

The bitcoind-miner itest configuration was removed from per-PR CI
because it varies no production lnd code: the miner is the lntest
harness's block generator. Its real purpose is validating lntest's
bitcoind miner support, which downstream projects consume.

Restore that coverage with a dedicated path-filtered workflow that
runs the configuration only when lntest itself (or the workflow)
changes, on PRs and on pushes to master. This keeps the validation
where it is relevant without spending a runner slot on every push.

Note that the new check must not be marked required in branch
protection, since it does not run on most PRs.

The two sqlite itest configurations were the slowest single-runner
jobs left at 31-32 minutes, still running SMALL_TRANCHES (8). The
basic configurations demonstrate that a single runner handles 16
tranches in about 20 minutes, since the itests are wait-bound
rather than CPU-bound and benefit from finer-grained tranches.
Switch the job to TRANCHES (16), leaving SMALL_TRANCHES to the
windows and macOS jobs.

Two CI runs of data show the tranche holding both channeldb and
invoices is consistently the slowest at 24-28 minutes against 12-17
for its siblings, with channeldb the heaviest package by a wide
margin. Reorder HEAVY_PKGS so that under the four-tranche CI split
channeldb shares a tranche only with light packages and invoices
moves next to chainntnfs. The partition remains disjoint and
covering (verified across all four tranches).

The three cross-compile jobs built all 18 release targets on every
push, costing roughly 45 runner-minutes per run. Platform-specific
compile errors come in a small number of classes (OS family, word
size, ARM), so build one job with one target per class instead. The
full target list is still built by the release workflow.

Experimental: revert this commit to restore the full per-PR matrix.

The btcd configuration differs from the bitcoind one only in the
chain-access layer (BtcdNotifier and the rpcclient paths), which the
chainntnfs interface test suite exercises against a real btcd node
in the unit jobs on every PR. btcd itself also runs as the miner in
every other itest configuration. This is the same reasoning that
removed the rpcpolling and notxindex configurations.

Experimental: revert this commit to restore the configuration.

The SQL itests formed a 2x2 product of engine (sqlite, postgres) and
store mode (kv shim, native SQL experiment). Two cells cover all the
main effects: postgres-native-experiment, where active native-SQL
development and the hardest concurrency semantics live, and
sqlite-shim, which covers the sqlite engine and the (stable,
engine-generic) shim layer. The dropped interactions keep unit-level
coverage on every PR: shim-on-postgres via the kvdb_postgres unit
variant and native-on-sqlite via the test_db_sqlite unit variant,
which also includes any in-flight dev migrations. What is lost is
only the whole-daemon run of those two cells, at a saving of roughly
105 runner-minutes per run.

Experimental: revert this commit to restore the full matrix.

Prebuilding the windows itest binaries on linux barely moved the
job's duration: the Run itest step is 44 of its 45 minutes, so test
execution dominates, not compilation. The same wait-bound dynamics
that took the sqlite itests from 31 to 21 minutes when moving from
8 to 16 tranches should apply here, since the windows runner has
the same four cores.

Experimental: revert to SMALL_TRANCHES if the windows runner proves
unable to handle 16 concurrent tranches.