Vendored cardano-node config/protocol modules in unstable-cardano-tools have drifted from upstream

[dnadales]

Problem

unstable-cardano-tools carries hand-copied versions of several cardano-node modules: Cardano/Node/Types.hs, Cardano/Node/Protocol/{Cardano,Byron,Shelley,Alonzo,Conway}.hs, and Cardano/Tools/DBSynthesizer/Orphans.hs (which mirrors Cardano/Node/Configuration/POM.hs).
They are copied rather than imported because cardano-node depends on ouroboros-consensus, so a direct dependency would be circular.

Each copy records the source file but not the source commit:

-- DUPLICATE: mirroring parsers from cardano-node/src/Cardano/Node/Configuration/POM.hs

Without a pinned commit there is no signal when upstream changes.
A copy stays internally consistent: its record, its parser, and its consumer all agree, so it keeps compiling and running long after upstream has moved on.
The drift only surfaces as wrong behaviour against a real node config.

Evidence

NodeHardForkProtocolConfiguration is the clearest case.
Upstream grew a npcTest<Era>HardForkAtVersion :: Maybe Word field for every era, to schedule a hard fork by protocol version.
The vendored copy has none of them, and its consumer can only express epoch triggers:

-- Cardano/Node/Protocol/Cardano.hs
triggerHardForkDijkstra = case npcTestDijkstraHardForkAtEpoch of
  Nothing      -> Consensus.CardanoTriggerHardForkAtDefaultVersion
  Just epochNo -> Consensus.CardanoTriggerHardForkAtEpoch epochNo
  -- upstream also has a version trigger, which this copy cannot express.

The same type also held the development-eras flag under its old name.
That part was fixed in #2075 (commit 14a693b7e), but the missing version fields remain.

NodeByronProtocolConfiguration drifted the other way: it still carries npcByronApplicationName and npcByronApplicationVersion, which upstream removed.

The Cardano/Api/* modules are vendored from cardano-api in the same way and have not been checked.

Impact

#2075 was one symptom: db-synthesizer forged zero blocks on a Dijkstra config because the stale flag capped the protocol version below the era the config scheduled.
That specific case is fixed.
The remaining drift means db-synthesizer still cannot read a config that triggers a hard fork by protocol version, and the copies will keep drifting as upstream evolves.

Proposed approach

Re-port the vendored modules against a single pinned cardano-node commit (for example f924314, the revision used as the reference in #2075), and note that commit alongside the copies.
Most of the work is mechanical: align field sets, key names, and defaults with upstream, and drop the removed Byron fields.
The one piece of real work is wiring the version-trigger path in Cardano/Node/Protocol/Cardano.hs, which needs the new npcTest<Era>HardForkAtVersion fields and the CardanoTriggerHardForkAtVersion case.