Decide whether single-forward should also flush the verifier cache on a caller-supplied binding mismatch

Surfaced by the review of #17.

On a **terminal** channel-binding mismatch, the gateway flushes (`invalidate`) its verifier cache for the upstream tuple. The two forward paths currently differ for a **caller-supplied** event:
- single forward (`forward_chat_completion_request`): does **not** flush (avoids letting a caller's event evict a gateway-owned cache entry).
- middleware/failover: **always** flushes (conservative: a binding mismatch is exactly the "stale binding" signal worth flushing in a TEE gateway).

#17 makes this an explicit `always_invalidate_on_mismatch` flag and preserves both behaviors. Open question: should single-forward also always flush (security-conservative), or is the current guard correct (avoid caller-driven cache eviction)? Decide deliberately and unify if warranted. Not urgent; flipping `false`→`true` at the two single-forward call sites is the whole change.

Review #17's always_invalidate_on_mismatch flag and compare the single-forward path with the middleware/failover behavior described here. Decide whether caller-supplied binding mismatches should flush the verifier cache, then update the two single-forward call sites if warranted and unify the behavior.

Written by the indexing model from the issue text.