getoracles reports testnet operator names on mainnet: OracleDisplayNames() is not chain-aware

[BaumerCrypto]

OracleDisplayNames() in src/rpc/digidollar.cpp (line 249) is a single
slot-indexed std::vector<std::string> with no chain parameter. Every
getoracles caller gets the same 35 names regardless of which network the
node is on, so where the mainnet and testnet rosters assign a slot to
different operators, mainnet reports the testnet name.

Environment: DigiByte Core v9.26.5, mainnet, Ubuntu 24.04. Line numbers
below are from the current feature/digidollar-v1 tree and may drift.

What I'm seeing

Running against mainnet at v9.26.5, getoracles true returns slot 11 as
hallvardo. Mainnet chainparams.cpp line 413 has that slot as Crypto
Corner Shop:

{11, ParsePubKey("03b9ca28f68bbe4f0b6f93c08b184e81e11b754906f2426739a1cfee48508276ca"),
     "oracle12.digidollar.org:12024", true},  // Crypto Corner Shop (mainnet RC46 key)

Testnet line 803 is a different key and that one is hallvardo. Both
operators are real, one per chain. The key assignment is correct on both
networks, it's only the reported name that's wrong.

Two other slots show smaller drift in the same direction: slot 0 reports
Jared where mainnet chainparams says DigiByte.Io Oracle, and slot 31
reports Peer2Peer against Peer2Peer / DigiRoos. Those read as label
shortening rather than misattribution. Slot 11 is the one that names a
different party.

Why it matters

Anything reading getoracles on mainnet inherits the wrong attribution.
That includes the oracle page on digidollar.org and my own Gitter status
bot, which pings operators when their slot goes stale. Slot 11 has been
stale for days, so the alerts were naming and notifying someone who does
not hold that slot on mainnet.

Reproduce

digibyte-cli getoracles true | jq '.[] | select(.oracle_id==11) | {oracle_id, name, pubkey}'

Compare the returned name against the operator comment on the matching
vOracleNodes line in src/kernel/chainparams.cpp.

Note on test coverage

There's a second copy of the same list in src/test/oracle_rpc_tests.cpp
line 61 (oracle_names). Since the fixture repeats the values rather than
deriving them, the tests agree with the bug and no existing case fails.

Suggested fix

The names already exist per chain, as // comments on each vOracleNodes
entry, but comments don't compile so the RPC can't use them. Promoting the
operator name into OracleNodeInfo alongside id, pubkey and endpoint would
put it next to the key it describes and make drift structurally impossible,
at the cost of touching all four roster blocks. A smaller change is to key
OracleDisplayNames() on the active chain and keep two lists, which fixes
the symptom but leaves the same drift risk in place.

I'm happy to open a PR for either shape if you have a preference. In the
meantime I've added a local display-name override to my own tooling so my
posts stop misattributing slot 11, but that only fixes my output, not the
RPC everyone else reads.