mev_sendBundle rejected with -32025 "invalid flashbots signature" — identical signing code works for eth_sendBundle

## Summary

`mev_sendBundle` calls are consistently rejected with `-32025 invalid flashbots signature`, using the exact same signing implementation that works correctly for `eth_sendBundle` against the same relay.

## Error received

```json
{"jsonrpc": "2.0", "error": {"code": -32025, "message": "invalid flashbots signature"}, "id": null}
```

## What works fine (control case)

`eth_sendBundle` and `eth_callBundle` against `relay.flashbots.net`, using the same auth key and signing function below. These succeed consistently.

## Signing implementation (Python)

```python
message = encode_defunct(text=Web3.keccak(text=payload_str).hex())
signed_msg = Account.sign_message(message, private_key=FLASHBOTS_AUTH_KEY)
signature = f"{auth_account.address}:{signed_msg.signature.hex()}"
# sent as X-Flashbots-Signature header
```

## mev_sendBundle payload

```json
{
"jsonrpc": "2.0",
"method": "mev_sendBundle",
"params": [{
"version": "v0.1",
"inclusion": {"block": "0x...", "maxBlock": "0x..."},
"body": [
{"hash": "0x"},
{"tx": "0x", "canRevert": false}
]
}],
"id": 1
}
```

## What I've already ruled out

- Auth key correctness — verified length/prefix/suffix, same key works for `eth_sendBundle`
- Signing logic — identical to the proven-working `eth_sendBundle` implementation
- `privacy.builders` field — removed entirely per docs noting hash-referenced ("unmatched") bundles can't use `privacy`; same error persists regardless
- Also tested `mev_simBundle` with the same body shape — identical `-32025` error there too

## Question

Given identical signing code succeeds for `eth_sendBundle` but fails for `mev_sendBundle`/`mev_simBundle` against the same relay, is there a known difference in how MEV-Share specifically validates the signature — a different expected payload serialization, a registration/reputation requirement specific to MEV-Share endpoints, or something else I'm missing?

Happy to share more detail (redacted addresses/hashes) if useful. Thanks!

Start by comparing the request construction and signature validation paths for mev_sendBundle and mev_simBundle with the working eth_sendBundle path, using the provided Python signing code and JSON payload as the reproduction. Check the handling of X-Flashbots-Signature, hash-referenced transactions, and the documented privacy.builders restriction; done means identifying the specific incompatibility or confirming the required MEV-Share behavior.

Written by the indexing model from the issue text.