Ensure forced inclusions are constrained

[ggonzalez94]

The overall concern is as follows:
If forced inclusions are missused they can become a mechanism for regular transactions that just bypass the preconfer and even worst they can create large prover killer batches.

There are several mechanisms we could use to mitigate it, we've even had some discussions about having the forced includer pay a provability bond similar to the preconfer but on the L1 and have some dutch auction mechanism to determine the fee they should pay(immediate inclusion by a proposer means the batch was likely not difficult to prove, while it waiting for it to be due is a signal of it being more expensive or undesirable for proposers). Ultimately I think these mechanisms deter the original purpose of forced inclusions. They should be simple, and cheap for users to create in case they are being censored, but we still want to constrain them.

My proposal is as follows, and is implemented by the node and enforced by the prover:

1. forced inclusions proposals are limited to a single block(I think we already do that)
2. that block has a smaller gas limit, minimizing the impact of potential prover killer ops

[ggonzalez94]

@davidtaikocha @linoscope curious if you guys have thoughts on this

[dantaik]

@ggonzalez94 partially done:

• ✅ single block — enforced: LibForcedInclusion.sol:14 ("limited to 1 blob only, and one L2 block only"), and the rs driver replaces a forced-inclusion source with the default manifest when blocks.len() != 1 (taiko-client-rs .../derivation/pipeline/shasta/pipeline/mod.rs), per docs/Derivation.md.
• ❌ smaller gas limit — not implemented: forced-inclusion blocks inherit the parent gas limit (docs/Derivation.md); there's no forced-inclusion-specific cap in the rs constants/validation.

Do you still want the reduced gas-limit constraint for forced-inclusion blocks, or close this as good enough?