cl/beacon: publishing a block with blobs fails on a beacon node that did not produce it

## Problem

`broadcastBlock` resolves blobs from the node's local cache:

```go
bundle, has := a.blobBundles.Get(common.Bytes48(*commitment))
if !has {
return fmt.Errorf("missing blob bundle for commitment %x", commitment)
}
```

`blobBundles` is only populated when *that* node produced the payload, so any beacon node asked to publish a full block it did not build returns 500.

The blobs are already in the request. `parseRequestBeaconBlock` decodes a `DenebSignedBeaconBlock`, which carries `KZGProofs` and `Blobs`, but `postBeaconBlocks` passes only `block.SignedBlock` to `broadcastBlock` and the rest is dropped.

## Impact

Any setup where a validator client publishes to more than one beacon node. The producing node succeeds, the others fail. Only blob-carrying blocks are affected — a block with 0 blobs publishes fine on every node.

Seen on a mainnet validator with two beacon nodes:

```
Error from beacon node when publishing block: 500 "missing blob bundle for commitment &b80d7d60..."
```

The block itself was published by the producing node, so this is not currently a missed-block risk. It does mean the second node contributes nothing to blob propagation, and it produces a recurring error in validator client logs.

## Expected

Use the blobs and KZG proofs from the request body when present, falling back to the local cache only when they are absent.

## Pointers

- `cl/beacon/handler/block_production.go` — `broadcastBlock`, `postBeaconBlocks`, `parseRequestBeaconBlock`
- Both the pre-Fulu and Fulu paths do the same cache lookup.