O(1) TEE Registration Invalidations

# Context

In the event of a [TCB Recovery ](https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/trusted-computing-base-recovery.html), all of the TEE registrations that use that vulnerable TCB will need to be [invalidated](https://github.com/flashbots/flashtestations/blob/main/src/FlashtestationRegistry.sol#L229). If we don't do this, then those registered TDX devices could be used to put out fake but verifiable attestations and subvert the systems that use them

# Problem

Our current process for invalidating these TEE registrations is costly; it requires calling [invalidateAttestations](https://github.com/flashbots/flashtestations/blob/main/src/FlashtestationRegistry.sol#L229) all existing TEE registrations, which might be 10's of them since we plan to deploy a new TDX device every week. This operation is costly because it requires calling the Automata `verifyAndAttestOnChain` function and verifying the whole attestation onchain. This is also operationally a burdensome.

# Potential Solution

We still need to nail down exactly what code within flashtestations and automata needs to change, but it's clear it's possible for each call to `BlockBuilderPolicy:isAllowedPolicy` to check if the workload's TEE registration is using a vulnerable TCB, and then use that information to invalidate the registration cheaply.