ci: route validation by changed surface

[aryamantodkar]

Why

Premove ITN had the deterministic harness from the earlier optimization stages, but unlike Premove it still ran the Python, Rust, and release-wheel jobs on every pull request. Its root agent guidance also retained several older generic rules that Premove has since simplified.

This change ports the generic improvements without copying Premove-specific runtime assumptions.

Changes

• Add changed-surface classification for five independent CI surfaces: agent harness, documentation, Python, Rust, and package.
• Add a stable final CI gate that requires every selected job.
• Run harness and docs checks in lightweight dev-only environments instead of installing the model stack.
• Treat Rust changes as cross-language changes: they select Python, Rust, and package validation.
• Treat unknown paths conservatively by selecting the full CI set.
• Keep policy-only files such as AGENTS.md and AGENT_HARNESS.md from triggering runtime suites.
• Align generic AGENTS.md rules with Premove: CodeGraph/rg usage, minimal abstractions, behavior-focused tests, deterministic evidence, richer branch/stacked-PR policy, proportional validation, RTK no-double-wrap guidance, and bootstrap-on-missing-CodeGraph behavior.
• Preserve all ITN-specific Rust/Python ownership, frozen-evaluation, inference-regression, model, package, and release invariants.

Routing

Changed surface	Harness	Docs	Python	Rust	Package
Policy only	—	—	—	—	—
Harness	✓	—	—	—	—
Public docs	—	✓	—	—	—
Python runtime/tests	—	—	✓	—	—
Rust	—	—	✓	✓	✓
uv.lock	✓	✓	✓	—	✓
Workflow / classifier / unknown	✓	✓	✓	✓	✓

The classifier or workflow changing selects the full set, so this pull request validates the new routing through all existing CI boundaries.

Deliberately not ported

• Premove's static agent-config test. It only freezes literal model/config values and does not validate behavior.
• Premove's smaller check.py. ITN's checker intentionally owns Rust, package, frozen-boundary, link, and clean-wheel validation.
• Premove runtime/ML path rules. ITN has different cross-language and release surfaces.

Review question

Does the changed-surface mapping preserve every validation boundary that can affect Premove ITN correctness or release artifacts while avoiding unrelated expensive jobs?