feat(code-graph): enrich member symbol identities for implementation links

[lsmonki]

Problem

Implementation tracking now supports symbol-level links, but code-graph does not appear to expose stable, expressive symbol identities for interface/class members.

In practice, links such as VcsAdapter.rootDir or ArchiveChange.execute can show up as stale even when the underlying member exists, because the graph may only expose a parent symbol (VcsAdapter, ArchiveChange) or a flat member name (rootDir, execute) instead of a stable composed member identity.

This makes symbol-level implementation links less reliable than they should be.

Requested change

Expand code-graph symbol identity for members so the graph exposes enough information to support precise implementation linking.

At minimum, member symbols should carry:

• the simple symbol name
• the member kind / form
  • method
  • property
  • getter
  • setter
  • constructor
  • field
  • static method
  • static property
  • interface member
  • and any other supported member form
• the composed owner-qualified identity, e.g. X.Y

Examples:

• VcsAdapter.rootDir
• ArchiveChange.execute
• CodeGraphProvider.analyzeSpecImpact

Why

This would let implementation tracking and any future graph consumers:

• create stable symbol-level links
• distinguish parent symbols from member symbols
• avoid false stale diagnostics caused by ambiguous or flattened symbol naming
• support better UX for symbol search, display, and impact analysis

Expected outcome

code-graph should expose member symbols with a canonical composed identity and enough kind metadata to disambiguate members reliably across indexing, search, and implementation-link materialization/review.