Eager push of partial messages

[lucassaldanha]

Support the "eager push" pattern used by Prysm: on first contact with a peer in a group (when we have no Recvd metadata for them yet), pre-emptively push available parts + header rather than waiting for a partsMetadata request from the peer.

Scope

This is predominantly a client-side (Teku) concern implemented inside PublishActionsFn. The jvm-libp2p API must not prevent it:

• PublishAction supports sending partialMessage and partsMetadata together in the same RPC.
• PublishActionsFn receives the full peerStates map, so the client can detect "no prior state for this peer in this group" and yield an eager-push action.

Verification

• Confirm the API shape supports Prysm's eager-push logic (see Prysm consensus-types/blocks/partialdatacolumn.go:311 forPeer).
• Consider whether we want to offer a convenience helper (optional, low priority).
• Document the pattern in docs/partial-messages.md so Teku developers can follow.

Known pitfall to document

Prysm hit a "send header only once per peer per group" bug fixed on 2026-03-31 (commit e8480a86). Per-group one-shot markers ("did we send the header to P?") must live inside PeerState, not in a separate side map. Document this as a gotcha for Teku developers.

Reference

Design: docs/partial-messages.md §4.3 (lands with the first PR on #435).
Prysm: prysm/partial-cells-current branch, commit e8480a86.