Python: Fix Purview cache size accounting when replacing entries - #8990

Motivation & Context

Growing a Purview cache entry at capacity could subtract its old size twice: once in set() and again when eviction encountered the still-live old mapping. A cache limited to 20 bytes could retain 24 estimated bytes while reporting 16, then report a negative size when emptied.

Description & Review Guide

• What are the major changes? Remove the previous cache mapping before subtracting its size and evicting entries. Add a regression test that grows the earliest-expiring entry while the cache is near capacity.
• What is the impact of these changes? Eviction skips the replaced entry's stale heap record and evicts another entry when needed. The replacement remains available, and size accounting returns to zero when it is removed.
• What do you want reviewers to focus on? The ordering of replacement removal and eviction, and the regression's assertions on retained values and tracked bytes.

Implemented and tested with Codex assistance on Linux/Python 3.12.14. The regression fails before the fix and passes afterward. All 200 Purview unit tests pass with 89% package coverage. Package Ruff, changed-file formatting, strict source Pyright, all five configured test type checks, source/wheel builds, and git diff --check pass.

Optional warning-level Pyrefly output contains three existing diagnostics in unchanged middleware tests, so the no-warnings checklist item is left unchecked. The complete repository and live-service integration suites were not run.

Related Issue

Fixes #8988

AI Assistance

• No material AI assistance was used.
• This is an AI-assisted contribution. I reviewed, understood, and verified all submitted content and accept responsibility for it.

AI assistance details: Codex assisted with issue analysis, implementation, regression tests, validation and the PR description.

Current status (10 November 2026)

The stale bot closed this PR after an inactivity warning; it was not merged. The fix still addresses the agreed issue, which is labelled ready-for-implementation. Current main at 13956ad8c0c52538dc8fb5abae549019fbf2dc83 has the same complete cache and cache-test files as the original base. The narrow issue reproduction against that main cache implementation still reports 16 bytes while holding 24, and -8 bytes after removal; its unused request-model import was stubbed, so this is not an end-to-end test. The preserved PR tree matches published head db8cc2e, and all 18 cache tests pass on Linux/Python 3.12.14. The 200-test Purview result above is the earlier PR-head validation, not a fresh current-main full-suite run.

Separate open draft #9607 handles values larger than the cache's total capacity; this PR handles double subtraction for replacements that fit. Both touch the same files.

The published head's Python test and quality jobs passed. The merge gate remains failed because its DevFlow prerequisite jobs were cancelled; the existing rerun request remains pending. No maintainer approval or fully green upstream CI is claimed.

Contribution Checklist

• The code builds clean without any errors or warnings
• All unit tests pass, and I have added new tests where possible
• The PR follows the Contribution Guidelines
• This PR is linked to an issue and there is no other open PR for this issue (see Related Issue above).
• This is not a breaking change. If it is a breaking change, add the breaking change label (or add "[BREAKING]" to the title prefix, before or after any language prefix) — a workflow keeps the label and title prefix in sync automatically.