fix(p2p): reject proposal when expected proposer is undefined

[spalladino]

Summary

Experiment to validate A-1326: when getProposerAttesterAddressInSlot resolves to undefined, ProposalValidator currently skips the proposer-identity check entirely and accepts the proposal. This applies the audit's suggested fix — reject instead of skip — mirroring CheckpointAttestationValidator, which already rejects in the equivalent case.

Note: expectedProposer resolves to undefined specifically when the committee is configured empty (targetCommitteeSize == 0, i.e. permissionless/open-committee mode where "anyone may propose") — sequencer.ts's checkCanPropose treats that same case as canPropose = true for every node. This PR is intended to surface, via CI (in particular any multi-node/permissionless e2e coverage), whether rejecting proposals in that mode breaks anything that currently relies on it.

Test plan

• Updated proposal_validator.test.ts's "open committee" cases to expect rejection instead of acceptance
• yarn workspace @aztec/p2p test src/msg_validators/proposal_validator/proposal_validator.test.ts passes locally (49/49)
• yarn build passes
• Relying on CI (multi-node/e2e) to reveal any behavior that depends on the previous accept-when-undefined path

[AztecBot]

Flakey Tests

🤖 says: This CI run detected 2 tests that failed, but were tolerated due to a .test_patterns.yml entry.

\033FLAKED\033 (8;;http://ci.aztec-labs.com/c36c1f14c01fd413�c36c1f14c01fd4138;;�): yarn-project/kv-store/scripts/run_test.sh src/bench/sqlite-opfs-encrypted/map_bench.test.ts (1s) (code: 0)
\033FLAKED\033 (8;;http://ci.aztec-labs.com/c1d2e66901bdfd62�c1d2e66901bdfd628;;�): yarn-project/kv-store/scripts/run_test.sh src/sqlite-opfs/internal/ordered-binary-browser.test.ts (2s) (code: 0)