Eager push of partial messages

Nobody has claimed this yet.

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](../blob/develop/docs/partial-messages.md) (lands with the first PR on #435).
Prysm: `prysm/partial-cells-current` branch, commit `e8480a86`.

Read docs/partial-messages.md §4.3, then inspect PublishActionsFn and the PublishAction API to confirm whether partialMessage and partsMetadata can be sent together. Compare the behavior with Prysm's partialdatacolumn.go:311 and document the per-peer, per-group header gotcha; done means the API supports the eager-push pattern and the pattern is documented for Teku developers.

Written by the indexing model from the issue text.