feat(pipelining): complete attestations by build-slot end

[spalladino]

Motivation

Under today's pipelining schedule, attestations for slot N's checkpoint trail into slot N+1 by blockDuration + p2pPropagationTime (~8s with defaults), which delays the L1 propose tx and pushes it toward the 3rd L1 block of the target slot. Shifting the broadcast ~8s earlier lets attestations finish by the build-slot boundary so the proposer can submit to L1 immediately at the target-slot start.

Approach

Updates the pipelined timing model to reserve assembly, round-trip p2p, and last-block re-execution at the end of the build slot (rather than leaking into the target slot). Proposal broadcast now fires at ~T = slotDuration − timeReservedAtEnd inside the build slot, so attestations arrive before the boundary. Receiver acceptance windows are tightened accordingly: proposalWindowIntoTargetSlot drops from p2pPropagationTime to 0 (only clock-disparity grace remains) and attestationWindowIntoTargetSlot shrinks from slotDuration − l1PublishingTime (60s at defaults) to 2·p2pPropagationTime (4s).

No new p2p validation path is needed: the main messageSlot === targetSlot || messageSlot === nextSlot check already covers the steady state under pipelining.

Changes

• stdlib (timetable): PipelinedCheckpointTimingModel.timeReservedAtEnd is now checkpointAssembleTime + 2·p2pPropagationTime + blockDuration; pipeliningAttestationGracePeriod drops to 0 under pipelining. proposalWindowIntoTargetSlot drops to 0 and attestationWindowIntoTargetSlot shrinks to 2·p2pPropagationTime.
• p2p (msg_validators): Tightens PipeliningWindow.acceptsProposal / acceptsAttestation via the new timing-model values; isWithinPipeliningWindow JSDoc is refreshed to describe the straggler-acceptance role explicitly.
• sequencer-client (README): Rewrites the pipelining section to describe the new schedule (broadcast inside build slot, attestations in hand by slot boundary, L1 submission at target-slot boundary) and refreshes the worked example.
• tests (stdlib, p2p, sequencer-client): Updates pipelined timing / window-size assertions and tightens acceptance tests for the shorter straggler windows.

Rollout notes

The tightened straggler windows mean a receiver running this change will reject stale-schedule proposals that arrive more than 500ms into the target slot and stale-schedule attestations that arrive more than 4.5s into the target slot. Expect to roll this out across validators together (the merge-train/spartan flow already batches validator upgrades) rather than mixing old and new schedules on a live network.