Missing SPO reward in epoch 211

[sandtreader]

Rewards diverge at epoch 211:

2025-10-27T17:14:20.676101Z ERROR acropolis_module_accounts_state::verifier: Missing reward: SPO c63dab6d780a74cbae2a27696c9723f55b3092b2bd001256df03827f account 0160fffc9996829dcfcedff505040d72b4eb73baae5008433ffbcc36 Leader 715140393
2025-10-27T17:14:20.679365Z ERROR acropolis_module_accounts_state::verifier: Rewards verification: errors=1 epoch=211

We thought this SPO's reward account was deregistered so don't pay the reward:

2025-10-27T17:14:18.527207Z  INFO acropolis_module_accounts_state::rewards: Calculating rewards: epoch=211 go=209 mark=211 total_supply=31737719158318701 total_active_stake=10177811974822904 stake_rewards=31834688329017 total_blocks=1991
2025-10-27T17:14:18.541493Z  INFO acropolis_module_accounts_state::rewards: Reward account for SPO c63dab6d780a74cbae2a27696c9723f55b3092b2bd001256df03827f was deregistered
2025-10-27T17:14:18.542037Z  INFO acropolis_module_accounts_state::rewards: SPO c63dab6d780a74cbae2a27696c9723f55b3092b2bd001256df03827f's reward account 0160fffc9996829dcfcedff505040d72b4eb73baae5008433ffbcc36 not paid 715140393

This is similar to the previous block point at 213 but for some reason is now happening earlier. Suspect we are mis-handling the timing of SPO reg/dereg w.r.t. reward epochs.

[sandtreader]

Note marked for Data Node because reasonably sure this will still be relevant post-Conway.

[sandtreader]

Well, this is a deep, dark rabbit hole...

The problem seems to arise because this SPO first registered with a testnet reward address (e00160fffc), although it later fixed it to mainnet (e1...). The regression happened because we now store stake addresses by full StakeAddress, including the network ID, where we previously stored them only has hashes, which are the same. Because the testnet address now doesn't match any registered stake address (which was mainnet), the reward isn't paid.

But this reveals a deeper problem - the SPO does then reregister the pool with the correct address, but this doesn't get through to AccountsState, or at least not in time. Digging further...

[sandtreader]

Well it looks like our timing is right, and their fix to use a mainnet address didn't arrive in time to count in epoch 211 (snapshot 209) or 212 (snapshot 211). Hence I can only assume the Haskell node ignored the bad address and indexed only by hash, as we used to!

I've fixed this by forcing the networkId when we convert from Pallas to PoolRegistration in map_parameters.