Add Solana Support

[josephinney]

Description

This PR adds full support for Solana to the pipeline.

Note on related work: I'm aware of #168, which also adds Solana support but appears to have stalled while awaiting changes since late 2025. I opened this PR because it takes a different approach in a few areas that may be useful to compare, and I'm very happy to consolidate, defer to, or combine efforts with that PR, whatever the maintainers prefer. Key differences:

• Data for Solana is collected from a Solana RPC node via a dedicated tool (solana-block-harvester). (PR feat(solana): wire with samples & tests #168 uses BigQuery)
• Mapping uses a dedicated SolanaMapping (inheriting from DefaultMapping with exact identifier lookup), rather than DummyMapping, which aligns with the review feedback given on feat(solana): wire with samples & tests #168.
• identifiers/solana.json is keyed by validator vote account, sourced from Solana's on-chain Config program.

Approach

Solana is conceptually similar to Cardano (data arrives already parsed, mapping is an exact identifier lookup rather than a substring match), with one key difference: the identifier (vote account) and the reward address (identity account) are distinct values, whereas in Cardano the pool hash serves as both. The vote account is used as the identifier because it is stable and permanent, whereas a validator's identity account can be rotated over time.

Main changes:

• SolanaMapping: exact vote-account identifier lookup, single identity-account address lookup.
• Registered Solana in ledger_parser (reusing DummyParser) and ledger_mapping.
• Added mapping_information/identifiers/solana.json (validator metadata).
• Added Solana to config.yaml.
• Unit tests for the Solana parser and mapping, with a curated sample.
• Documentation across README, index, parsers, mappings and data pages.

Two pipeline-wide notes:

• get_reward_addresses now accepts the list-form reward_addresses from the EDI data-format spec (e.g. ["addr"]) in addition to the comma-separated string. Backward compatible and benefits all ledgers.
• No queries.yaml entry is added, as Solana is not collected via BigQuery in this PR.

Clustering (addresses/clusters mapping information) is intentionally left for a follow-up, to be coordinated with the maintainers.

All tests pass (45 passed). Note: mapping_information/cardano_preprocessing is excluded from the local run because its BigQuery/protobuf dependency is incompatible with Python 3.14 (unrelated to Solana, pre-existing). The Solana parser and mapping tests are included and passing.

Checklist

All Submissions:

• Have you followed the guidelines in our Contributing documentation?
• Have you verified that there aren't any other open Pull Requests for the same update/change? — See feat(solana): wire with samples & tests #168, which also adds Solana support (currently stalled awaiting changes). This PR is a deliberate alternative, i am happy to consolidate as the maintainers prefer.
• Does the Pull Request pass all tests?

New Ledger Support Submissions:

• What mapping information did you add for the new ledger?
  • identifiers
  • addresses
  • clusters
  • legal links
• Did you create a new parser?
  • If no, which parser did you reuse?
    • DummyParser
• Did you create a new mapping?
  • If yes, did you create a unit test for the new mapping?
• Did you enable the parser for the new ledger in consensus_decentralization/parse.py?
• Did you enable the mapping for the new ledger in consensus_decentralization/map.py?
• Did you document support for the new ledger as described in our Contributing documentation?