Classify Python type declarations with semantic kinds

[Widthdom]

Summary

• Store Python PEP 695 aliases and TypeAlias / NewType declarations as typealias.
• Store TypeVar / ParamSpec / TypeVarTuple declarations as type_parameter, register both kinds across schema, query hints, and completions, and expose their type compatibility family.
• Bump the Python extractor contract so a normal index refresh migrates unchanged files, with regression, query, schema, documentation, and bilingual changelog coverage.

Root cause

The Python symbol extractor classified local type declarations with the import kind. The public kind catalog did not contain a dedicated type-parameter kind, and unchanged Python files would otherwise retain the old persisted classification after an upgrade.

Validation

• dotnet build CodeIndex.sln -c Release --no-restore -p:UseSharedCompilation=false — passed with 0 warnings and 0 errors.
• Focused Issue Store Python type aliases and type parameters with semantic symbol kinds #4615 tests — passed on .NET 8 and .NET 9 (30 each).
• Documentation contract tests — passed on .NET 8 and .NET 9 (13 each).
• dotnet run --project tools/CodeIndex.Changelog -- check — validated all 79 fragments.
• dotnet format CodeIndex.sln --verify-no-changes --no-restore — passed.
• Full Release suite — .NET 9 passed (9,239 passed / 410 skipped); .NET 8 had one unrelated hook-isolation flake (9,703 passed / 6 skipped / 1 failed), whose isolated rerun passed and is tracked by Stabilize post-extraction hook isolation test in the full net8.0 suite #4689.
• Codex adversarial review — the initial persisted-row invalidation finding was fixed by the Python extractor contract bump; round 2 reported No blocking/actionable issues found.

Follow-up candidates

• Align symbols --results-only support with the README contract #4688
• Stabilize post-extraction hook isolation test in the full net8.0 suite #4689

Fixes #4615