Is your feature request related to a problem? Please describe.
In architectures that utilize rollup-boost with both a "Canonical" EL (e.g., local op-geth) and a "Remote" Builder (e.g., op-rbuilder), the existing configuration slots are fully occupied.

There is currently no native way to forward Engine API calls to an external observer (a "shadow builder") for debugging or testing purposes without placing a separate proxy (like bproxy or proxyd) in front of the entire stack. We need a way to validate new builder logic, log transaction timings, and debug complex scenarios (like transaction replacements) in a live environment without risking the stability of the active sequencer or block production.

Describe the solution you'd like
Extend rollup-boost to support a "Shadow Builder" target URL via a CLI flag or configuration file.

Proposed Behavior:

• Configuration: Add a flag (e.g., --shadow-builder-url or --shadow-target) to accept a secondary builder endpoint.
• Async Fan-out: When rollup-boost receives Engine API calls (specifically forkChoiceUpdated and newPayload), it should asynchronously "fire and forget" these calls to the shadow target.
• Non-Blocking: The shadow target path must be strictly non-blocking. Latency, timeouts, or failures in the shadow builder should not affect the primary builder flow or trigger fallback logic.
• Scope: The shadow builder is not intended to submit blocks back to the sequencer; it uses these signals solely to maintain state and log data for analysis.

Describe alternatives you've considered

• External Proxies: We considered placing a generic proxy in front of rollup-boost to fan out requests. However, this adds unnecessary infrastructure complexity and overhead for what should be a straightforward mirroring feature within the sidecar itself.
• Multiple Remote Builders: While theoretically possible to configure multiple remotes, existing fallback logic is generally binary (Primary -> Fallback). It is not designed for a "Primary + Silent Observer" relationship.

Additional context
This feature is distinct from the primary fallback logic (Local vs. Remote). It requires a simple addition to the request handling logic where the request is mirrored to the shadow URL if the flag is present, ensuring zero impact on the critical path.