`addPayloadEnvelope` should be idempotent for API/gossip race

[lodekeeper]

Context

In PayloadEnvelopeInput.addPayloadEnvelope(), a second call throws "Payload envelope already set". This is reachable from external input paths when API and gossip race:

1. API handler receives envelope, sleeps for slot boundary alignment
2. Gossip envelope arrives during the sleep, gets added first
3. API handler wakes up and calls addPayloadEnvelope() → throws → 500 error to the VC

This is relevant in multi-node or DVT setups where the proposer's envelope arrives via gossip before the API call completes (similar to #8849).

Proposed fix

Make addPayloadEnvelope() idempotent — silently return (or log) if the envelope is already set, matching the dedup semantics of shouldImport(). At minimum, the API handler should catch this gracefully instead of returning a 500.

References

• PR feat: add gloas execution payload envelope import pipeline #8962 — payloadEnvelopeInput.ts (review comment)
• Issue Queuing on api if execution payload envelope is received first #8915 — parallel block + payload submission
• PR fix(api): allow duplicate columns/blobs in publishBlock for multi-BN setups #8849 — similar race condition handling

/cc @nflaig @twoeths

[markolazic01]

Implicitly resolved in #9595, though some additions can be made per #9504 (comment)

[lodekeeper]

Confirmed against current unstable after #9595: the original API/gossip race is resolved.

There are now two successful duplicate paths in publishExecutionPayloadEnvelope():

• If gossip wins before/during API validation, validation raises ENVELOPE_ALREADY_KNOWN and the stateful API path treats it as a successful publish retry instead of returning a 500.
• If gossip wins after validation or during the slot-boundary sleep, the later payloadInput.hasPayloadEnvelope() guard skips the second addPayloadEnvelope() call, so the API handler no longer trips the Payload envelope already set throw.

I would keep this issue open as the reminder Nico mentioned for the remaining narrower follow-up from #9504: add an adapted warning/tests for already-known envelopes whose incoming payload block hash diverges. First-time payload-vs-bid hash mismatches are still rejected, but the already-known path short-circuits before that comparison, so that observability/test coverage is the only leftover value I see.