Python stub-cache pruning still evicts actively used entries by age #1530

Problem

Source-revalidated on main 3f2a835c78e9daba7baefc4c018c6fc9ca3c6e4a.

Publication no longer restores an old source timestamp, fixing premature eviction of freshly copied old stubs. However, existing newer cache files skip copy without touching use time, environment/view use does not refresh age, and the janitor removes files solely by mtime with no live-workspace protection.

Location: crates/prod-code-gateway/src/python_cache/fs_ops.rs:72-81; crates/prod-code-gateway/src/python_cache/merge.rs:103-119; crates/prod-code-gateway/src/python_cache/prune/unix.rs:102-112.

Reproduction boundary

A continuously used namespace can reach the configured max age even though analyzers keep reading its stubs; a prune pass then removes them. This is the remaining active-use part of the original finding, not a claim that publication-time handling is still broken.

Expected correction

Track last use or active namespace leases separately from source freshness, and prune only entries that are actually idle. Preserve the corrected publication behavior and verify active versus inactive aging using controlled clocks/temporary cache fixtures.

Verification limits

Read-only production/test source inspection, including the current-main acceptance-test diff (formatting changes do not alter the tested boundary). No destructive cleanup, cache mutation, benchmark, new tests, child processes or server restarts were executed. Outcomes above are source-derived, not fresh runtime results.

Original review findings

• feat(gateway): shared Python virtual-environment stub cache and worktree seeding (Phase 3.6) #835 (comment)