refactor(cache): restructure the cache entry around fs and env fingerprint records

[wan9chi]

Motivation

The cache entry conflates three records with different validation stories: the listed inputs' pre-run content hashes (globbed_inputs), the traced-access fingerprints (inside PostRunFingerprint), and the tracked env state (also inside PostRunFingerprint) — with the change-kind vocabulary living in the cache module, creating a module cycle with the fingerprint module.

This regroups them by what they mean, as groundwork for extracting the filesystem story into its own crate (stack: 1/3):

• InputFingerprints — everything the run read: the listed-inputs snapshot and the discovered-input fingerprints, one opaque serialized value owning its own validation (find_change).
• TrackedEnvFingerprints — everything runner-aware tools observed in the env, owning validate_envs (new post_run.rs, dissolving PostRunFingerprint).

Lookup and update control flow is unchanged. The entry layout changes, so CACHE_SCHEMA_VERSION bumps 18 → 19; existing caches are ignored once via the versioned cache directory.

🤖 Generated with Claude Code

[github-actions]

fspy benchmark

linux

dynamic/launch             change  +0.33%  [ -3.16% ..  +5.03%]  overhead   +58.22%
dynamic/access             change  -0.13%  [ -1.40% ..  +1.04%]  overhead    +6.97%
static/launch              change  +1.74%  [ -2.89% ..  +7.47%]  overhead  +164.67%
static/access              change  -0.22%  [ -1.66% ..  +1.68%]  overhead  +817.27%

macos

dynamic/launch             change  -0.15%  [ -2.61% ..  +3.29%]  overhead  +218.58%
dynamic/access             change  +0.36%  [ -2.06% ..  +2.17%]  overhead    +4.40%

windows

dynamic/launch             change  -0.33%  [ -1.52% ..  +1.74%]  overhead   +28.21%
dynamic/access             change  +0.38%  [ -0.58% ..  +0.95%]  overhead    +1.39%