fix(oo-v3): revalidates cached whitelist entries

[tcoatswo]

Motivation

OptimisticOracleV3 caches positive collateral and identifier whitelist results
to avoid repeated external calls. The current positive-cache fast paths treat
those results as non-revocable: after governance removes a previously cached
currency or identifier, assertTruth continues to accept it until an external
caller explicitly invokes syncUmaParams.

This bypasses the live governance state for new assertions. A removed
identifier has an additional failure mode because the DVM revalidates the
identifier when a dispute requests a price. OOv3 can accept the assertion from
its stale cache while the DVM rejects the dispute against the live whitelist.
The reverted dispute leaves the assertion undisputed, allowing it to settle as
true after liveness.

A removed collateral currency can likewise continue securing new assertions
even when governance has determined that the token is no longer suitable.

Summary

• Revalidate identifier support against the live identifier whitelist for
  every new assertion.
• Revalidate currency support against the live collateral whitelist for every
  new assertion.
• Preserve final-fee caching: the Store is queried only when a whitelisted
  currency is first added or re-added to the OOv3 cache.
• Add regression tests proving that removal of a previously cached identifier
  or currency immediately blocks new assertions without requiring
  syncUmaParams.

Details

The identifier path no longer returns early on a cached true value. It
updates the cached value from IdentifierWhitelist.isIdentifierSupported on
every validation.

The currency path first checks AddressWhitelist.isOnWhitelist live. If the
currency has been removed, validation returns false. If it is live-whitelisted
but is not currently represented by a positive cache entry, OOv3 restores the
entry and fetches its final fee. Existing positive entries continue to reuse
their cached final fee.

This keeps the expensive Store lookup cached while ensuring that revocable
authorization is never inferred solely from stale local state.

The change affects only creation of new assertions. Existing assertions retain
their recorded currency and identifier and continue through their existing
lifecycle.

Testing

• Ran end-to-end test, running the code as in production
• New unit tests created
• Existing tests adequate, no new tests required
• All relevant existing tests pass
• Untested

Command:

forge test --match-path 'test/foundry/optimistic-oracle-v3/OptimisticOracleV3.*.t.sol'

Result:

33 tests passed; 0 failed; 0 skipped

Issue(s)

Security-sensitive fix. No public issue was opened before the patch to avoid
publishing the vulnerable behavior without a proposed remediation.