Bundle passes validation step but fails to be sent to builder using `refund-recipient`

## Description

There is a special case of nested bundles that can be sent to builders using the `v1.0` format but will fail to be sent to builders using `refund-recipient`

I identified this potential bug during a code review. I haven't tested it yet but my observations lead me to believe it's a bug.

## Reproduction Steps

1. Send a bundle `B1` from searcher `S1` that contains an inner bundle but all elements are matched. Set privacy hints so that the bundle is shared in the hint stream
```
body:
bundle:
tx: "0x1..."
tx: "0x2..."
```

2. Create a new bundle `B2` from searcher `S2` that backruns bundle `B1`. Make sure to set a builder in the privacy settings that relies on the `refund-recipient` format
```
body:
hash: "0x3..."
tx: "0x4...
```

## Expected Behavior

The bundle is sent to both the flashbots builder and the external builder.

## Actual Behavior:

The bundle will be sent to the flashbots builder, since it relies on the `v1.0` format, but not to the builder relying on the `refund-recipient` format.

## Additional Context:

The bundle `B2` [passes the validation](https://github.com/flashbots/mev-share-node/blob/afe43e7c4bcb89b091aca5d1e4d20dd8f2403fa0/mevshare/api.go#L91C41-L91C41), because the max nesting level is 0.

The unmatched bundle [gets matched](https://github.com/flashbots/mev-share-node/blob/afe43e7c4bcb89b091aca5d1e4d20dd8f2403fa0/mevshare/api.go#L128).

```
body:
bundle:
bundle:
tx: "0x1..."
tx: "0x2..."
tx: "0x4...
```

When the bundle gets sent to a builder that relies on the `refund-recipient` format the bundle must be converted. In the conversion the transactions are extracted, but this time the [bundle will throw an error](https://github.com/flashbots/mev-share-node/blob/afe43e7c4bcb89b091aca5d1e4d20dd8f2403fa0/mevshare/refund_recipient.go#L13C17-L13C17) because the nesting level is 2.