As discussed with @vedhavyas, the solution to this issue would be adding a new variant of the invalid bundle fraud proof.

Currently, we have 2 variants of the invalid bundle fraud proof in general:

• TrueInvalid, proving extrinsic at the specific index of the bundle is invalid
• FalseInvalid, proving the invalid extrinsic claimed by the bad ER is actually valid

We need to introduce a new variant called UnknownInvalid (better naming is surely welcomed!), proving the invalid extrinsic claimed by the bad ER does not exist at all.

The honest operator will generate this fraud proof variant if it finds:

• A bad ER that has a mismatched ER::inboxed_bundles field
• And the ER::inboxed_bundles[mismatched_idx] is an invalid bundle that invalid_bundle_type.extrinsic_index() >= total_tx_count, where the total_tx_count is the total number of tx contained inside the given bundle

The UnknownInvalid bundle fraud proof only needs to contain data necessary to locate the controversial bundle, i.e. bad_receipt_hash, domain_id, and bundle_index.

The consensus node (the verifier) will verify this fraud proof by extracting the total_tx_count through the host function and checking the bad ER:
ER::inboxed_bundles[bundle_index].invalid_bundle_type.extrinsic_index() >= total_tx_count

cc @vedhavyas @dariolina

Makes sense to me. Though it seems like there is a way to merge this case into the FalseInvalid variant, by making it check that the claimed invalid index is within bounds and only if so generate proof_of_inclusion. If invalid_bundle_type.extrinsic_index() >= total_tx_count then we send None instead of proof_of_inclusion.
Or, if we make a new type, I suggest you can extend the names for more clarity to TrueInvalidExtrinsic, FalseInvalidExtrinsic, then the new variant can be MissingInvalidExtrinsic or AbsentInvalidExtrinsic

I'd like to double down on making this case a FalseInvalid since we use it not only just to show that a bundle is not Invalid but also that InvalidBundleType is unjustified (i.e. incorrect type or extrinsic index), then it makes sense for a InvalidBundleType(non-existent-extrinsic-index) to fall into this category.

Yeah, I'm okay with reusing the FalseInvalid variant to handle the issue.