feat(client): spawn LH PayloadAttestationService with AnchorValidatorStore backend

[shane-moore]

Goal

Wire anchor/client/src/lib.rs to spawn Lighthouse's PayloadAttestationService with AnchorValidatorStore as the backend. The pattern mirrors the existing AttestationServiceBuilder spawn (currently around client/src/lib.rs:654-661, with start_update_service around line 717-719). This completes the PTC pipeline: LH's service drives sign_payload_attestation (from #1037) per validator at 75% slot.

Context

Per SIP-94 §3 (ssvlabs/SIPs#94), Lighthouse provides PayloadAttestationService as part of its validator-services crate. Anchor inherits duty fetching, slot timing, and per-validator dispatch from LH (per Anchor's LH-constraint operating principle); the only Anchor-side wiring is the client startup that constructs the service builder and spawns the update loop.

After this PR lands, PTC is end-to-end operational: BN -> #1036's phase publishes context -> LH service triggers at 75% slot -> #1037's sign_payload_attestation runs QBFT + signing -> reconstructed PayloadAttestationMessage posts back to BN via LH.

Suggested approach

anchor/client/src/lib.rs:

• Next to the existing AttestationServiceBuilder construction, build a PayloadAttestationServiceBuilder with duties_service, slot_clock, validator_store, beacon_nodes, executor, chain_spec.
• Next to the existing start_update_service calls, call start_update_service on the new service.

Sketch (verify against the actual builder signature at PR time — see Open questions):

let payload_attestation_service = PayloadAttestationServiceBuilder::new()
    .duties_service(duties_service.clone())
    .slot_clock(slot_clock.clone())
    .validator_store(validator_store.clone())
    .beacon_nodes(beacon_nodes.clone())
    .executor(executor.clone())
    .chain_spec(spec.clone())
    .build()?;

payload_attestation_service.start_update_service(&executor)?;

Acceptance criteria

• Anchor's client startup spawns PayloadAttestationService alongside the existing LH services.
• The service drives feat(validator_store): implement sign_payload_attestation #1037's sign_payload_attestation per validator at 75% slot.
• Startup logs confirm the service is running.
• Smoke test on a kurtosis devnet (or ssv-mini) shows PTC duties being attempted post-Gloas; full coverage in M6.

Open questions

• Builder constructor. PayloadAttestationServiceBuilder::new() vs ::default()? Verify against LH's validator_services/src/payload_attestation_service.rs at PR time.
• Builder field list. The sketch lists six fields based on the AttestationServiceBuilder pattern but the actual builder signature has not been verified. Read the LH source before writing the call site.

Risks

• LH builder API drift between rev bumps. If LH's PayloadAttestationServiceBuilder signature shifts between the planning pin and the PR-time pin, mirror the change. No Anchor abstraction over the builder.