fix: change order of registry queries in reward manager

[shaspitz]

Describe your changes

This PR changes the order that validator registries are queried during RewardManager.payProposer.

Context

See https://cantina.xyz/code/e92be0b9-b4f2-4bf2-9544-ae285fcfc02d/findings?finding=107

Our validator registries do not validate BLS identities/signatures on-chain. However, pubkeys can be manually slashed via any of the registries, disincentivizing spoofed validator registrations.

The vanilla stake amount on mainnet is 1 eth, meaning the maximum punishment an attacker could incur is 1 eth in loss. Accumulated mev rewards for a pubkey can feasibly add up to more than 1 eth, possibly enabling an attacker to be profitable. The attacker could frontrun a valid receiver address from the MevCommitMiddleware contract for example, by registering a pubkey with accumulated rewards, to the vanilla registry.

To mitigate this attack, we should change the order of the queries in _findReceiver such that:

1. the MevCommitAVS is checked first, since pubkey registrations cannot be spoofed through eigenlayer due to their native restaking implementation
2. Next the MevCommitMiddleware contract should be checked, as pubkeys could be spoofed in that registry, but only from whitelisted operators (so our team would at least know the org/entity that's acting maliciously).
3. The vanillaRegistry is the only truly permissionless registry, so it should be checked last. Note an attacker cannot spoof a validator registration in the vanilla registry that already exists, see IVanillaRegistry.ValidatorRecordMustNotExist.

Following this change, the only negative outcome is that vanilla staked validators must trust all whitelisted symbiotic operators to not steal their rewards. This is an odd trust assumption and not ideal, but acceptable in practice.

The only fool proof long term solution here is to require that symbiotic and vanilla registered validators prove ownership of the BLS pubkeys they register.

Checklist before requesting a review

• I have added tests that prove my fix is effective or that my feature works
• I have made corresponding changes to the documentation