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

## 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:

```haskell
-- 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 `npcTestHardForkAtVersion :: 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:

```haskell
-- 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 `npcTestHardForkAtVersion` fields and the `CardanoTriggerHardForkAtVersion` case.

Compare the vendored Cardano/Node/Types.hs, Cardano/Node/Protocol/{Cardano,Byron,Shelley,Alonzo,Conway}.hs, and Cardano/Tools/DBSynthesizer/Orphans.hs modules with cardano-node at commit f924314. Align the copied fields, keys, defaults, and Byron records, then trace Cardano/Node/Protocol/Cardano.hs for the version-trigger path; done means the copies are pinned and db-synthesizer can represent the upstream configuration.

Written by the indexing model from the issue text.