Python: share the ty-types type registry across a project parse

[knutwannheden]

Motivation

rewrite-python's whole-project parse path (handle_parse_project, used by the CLI's mod build via rpc.parseProject) parses every .py file in a project through a single shared ty-types --serve session. ty's session deduplicates type descriptors: each type is emitted in full exactly once — in the first getTypes response that references it — and later responses reference it by id only.

But the parser builds a fresh per-file type registry, populated solely from that file's getTypes response. So any type first seen in an earlier file (e.g. pydantic.BaseModel) is absent from later files' registries, and supertypes pointing into it can't resolve. The net effect on a real multi-file repo: first-party classes in every file but the first lose their supertypes, self no longer resolves as a BaseModel subclass, and a type-aware recipe like ReplaceModelFieldsInstanceAccess silently does nothing across most of the project.

• This is a pre-existing latent bug, newly exposed by Python: accept a caller-provisioned dependency path for ty type attribution #7930 (the dependency-path work that made third-party supertypes resolvable in the first place). Single-file handle_parse does not hit it, because it creates a fresh ty session per parse, so every file is "first".

ty type ids are stable within a session (e.g. id 1 == BaseModel across all files), which is what makes a session-scoped registry sound.

Summary

• TyTypesClient now accumulates every descriptor returned across all getTypes calls into a cumulative, session-scoped session_types table, keyed by ty's session-stable type ids. The table is reset when a new session starts (a fresh client, or initialize with a different project root) so no state leaks across unrelated parses.
• PythonTypeMapping references that table and, in _build_index, back-fills any descriptor missing from the current file's own response (and seeds _class_literal_index from the cumulative class literals). File-local descriptors take precedence, preserving the existing FQN-based dedup of Class objects.
• This keeps ty's dedup performance benefit (descriptors are still emitted only once per session) while restoring correct supertype resolution in every file of a project.

Alternatives considered: (a) a fresh ty session per file in handle_parse_project — correct but re-initializes ty per file and loses the shared-session speedup; (b) a ty --serve "no-dedup" mode — least control and would regress payload size. The session-scoped registry retains the performance benefit and is fully under our control.

Test plan

• Added TestProjectParseSupertypeAcrossFiles to tests/python/test_type_attribution.py, exercising handle_parse_project exactly as mod build does. It uses two peer model files so the failure is order-independent (whichever file ty parses second loses its base), asserting that self resolves as a pydantic.main.BaseModel subclass in both files. Fails before this change (the second file drops the supertype), passes after.
• The single-file TestExternalSupertypeResolutionInParsePath positive/negative tests still pass.
• Full tests/python/test_type_attribution.py green (130 passed).
• Broader tests/python + tests/recipes suites green (1565 passed, 6 skipped).

(The new test relies on ty-types and uv being available and pydantic not being importable in the test interpreter; it skips otherwise by design.)