fix(validator): process block proposals from own validator keys in HA setups (backport #21603)

[AztecBot]

Summary

Backport of #21603 to v4-next.

In an HA setup, two nodes sharing the same validator keys would ignore each other's block proposals because validateBlockProposal returned early for self-proposals. This PR:

1. Removes self-filtering in validateBlockProposal so HA peers process proposals from their own validator keys
2. Reorders checkpoint_proposal_job to sign before syncing to archiver, preventing stale blocks in HA setups
3. Adds shared slashing protection for testing via createSharedSlashingProtectionDb (in-memory impl for v4-next)
4. Threads slashingProtectionDb through validator creation chain for HA test injection

Conflict resolution

The cherry-pick had conflicts in validator.ts due to different variable naming on v4-next (validatorKeyStore/haSigner vs slashingProtectionSigner on next). Resolved by adapting the new slashingProtectionDb branch to use v4-next's naming pattern.

Build adaptation

v4-next doesn't have LmdbSlashingProtectionDatabase, HASignerMetrics, or CreateLocalSignerWithProtectionDeps that exist on next. Created InMemorySlashingProtectionDatabase as a lightweight alternative for testing, and simplified createSignerFromSharedDb to work with v4-next's 2-arg ValidatorHASigner constructor.

Commits

1. Cherry-pick with conflicts — raw cherry-pick of 5eedb7d with conflict markers
2. Conflict resolution — resolve import and constructor conflicts in validator.ts
3. Build fixes — adapt factory functions for v4-next (in-memory DB, simplified deps)

ClaudeBox log: https://claudebox.work/s/5fffc97ddc02fa23?run=1