Checker: preserve semantic identities for properties and methods

Parent epic: #1390. Deferred from #1306.

## Goal

Extend checker-owned semantic identity from lexical/type/namespace/label bindings to property and method declarations and uses. The checker must retain enough declaration provenance to answer member navigation correctly; LSP handlers are a separate child.

## Current state

`BindingIndex` records stable identities for lexical and named type domains. Member resolution generally reduces class/interface/record metadata to string-keyed `TypeInfo` dictionaries. A successful check of `receiver.member` therefore knows the member's type but often loses which source declaration(s) established it.

## Semantic contract

A member occurrence may resolve to zero, one, or several declaration identities. Several is required for legal merging/overloads or union/intersection domains. Unknown or dynamic (`any`, index-signature-only, unresolved computed name) access must remain explicitly unbound rather than being guessed from text.

## Work

- [ ] Define a member-symbol/provenance model with stable identity, source document/token declarations, static/instance and public/private facets, overload/accessor participation, and checker-generation lifetime.
- [ ] Preserve member identities in class, generic-class, interface, record/object-literal, namespace-adjacent, enum, and external declaration metadata where a source declaration exists.
- [ ] Capture identities while collecting class fields, methods, accessors, auto-accessors, constructor parameter properties, interface/type-literal members, and mergeable declarations.
- [ ] Carry identities through class freezing, generic instantiation/substitution, heritage traversal, interface merging, aliases/imports/re-exports, mapped/utility types where provenance remains meaningful, and contextual object-literal typing.
- [ ] Bind member-name tokens in reads, writes, calls, compound/logical assignments, increment/decrement, optional chains, private access, `super`, and literal-key indexed access when checker resolution is exact.
- [ ] Define override and inheritance semantics: navigation can expose the selected declaration plus related override/base declarations without collapsing unrelated same-spelling members.
- [ ] Define structural semantics for records/interfaces/unions/intersections. Ambiguous compatibility must produce an explicit set or no binding, never a repository-wide text match.
- [ ] Treat computed symbol/string/number names, getters/setters, overload sets, static-vs-instance names, and same-name type/value facets deliberately.
- [ ] Keep built-in/.NET members navigable only when a real source or metadata location contract exists; otherwise return no source identity.
- [ ] Ensure binding storage is snapshot-safe and does not retain obsolete checker graphs.

## Verification

- [ ] Checker-level tests assert declaration/use identity for fields, methods, accessors, private members, statics, constructor parameter properties, and object/type-literal properties.
- [ ] Cover inheritance, overrides, interface extension/merging, generic bases and substitutions, overloads, getter/setter pairs, aliases/imports/re-exports, and cross-module declarations.
- [ ] Cover union/intersection receivers, contextual object literals, destructuring property names, mapped/utility types, optional access, literal-key index access, and computed well-known symbols.
- [ ] Negative tests prove unrelated structural types with the same property spelling are not conflated; `any`, dynamic string indexes, unresolved computed names, and failed checks do not fabricate identities.
- [ ] Tests cover shadowed lexical names versus member names and static/instance or public/private same-spelling members.
- [ ] Re-checking after an edit produces new-generation identities with no references to stale documents.
- [ ] Existing type-checker diagnostics and all current lexical navigation/reference/rename tests remain unchanged.
- [ ] Record checker time and retained-memory impact on a representative multi-project workspace; investigate and document any regression above 10%.
- [ ] Full unit, Test262, and TypeScript conformance validation is green.

## Success criteria

The checker can answer “which declaration domain produced this member token?” for every supported exact member resolution, represent multi-declaration domains explicitly, and conservatively decline ambiguous/dynamic cases without semantic or performance regression.

## Non-goals

- LSP locations/workspace traversal (follow-up child).
- Rename edits (later child).
- Text-search fallback for unresolved members.

Start by reading the checker’s BindingIndex and the member-resolution paths that currently reduce declarations to string-keyed TypeInfo dictionaries. Use the checker-level tests described in Verification to map the first supported declaration and use cases. Done means exact member resolutions preserve stable declaration identities, while ambiguous or dynamic accesses remain explicitly unbound without stale-generation references or regression in existing tests.

Written by the indexing model from the issue text.