Summary

• invalidate cached GET/HEAD/OPTIONS managed-tool results after a successful mutation
• also invalidate after an ambiguous mutating failure that may have committed
• preserve duplicate suppression for mutations and for repeated reads when no write intervenes

Why

A live get_trigger -> update_trigger -> get_trigger sequence replayed the pre-update cached GET in the final round. PostgreSQL and the update receipt had current state, but the model saw stale state and reported an apparent API revert. Read-after-write must execute again.

Verification

• go test ./internal/proxy
• go test ./...
• regression test proves the first post-mutation read executes and subsequent duplicates replay the refreshed result

Observed live intervention: duplicate_managed_tool_call:trading-api.get_trigger immediately after managed_tool_schema_rejected:trading-api.update_trigger.