docs(impact): record why the static-member pass stays off for TS/JS/Python

Measured an A/B of extending extractStaticMemberRef to TS/JS/Python: ZERO
coverage gain on both excalidraw (TS, 94.3%→94.3%) and requests (Python,
100%→100%), because in import-based languages a `Type.MEMBER` read requires
importing the type first, so the import edge already covers it — the static read
is pure duplication. Meanwhile it adds real graph noise (+1813 edges / +2448
`references` on excalidraw, the retrieval-perf benchmark, all pointing at
already-covered types). Reverted the extension; documented the finding in the
STATIC_MEMBER_LANGS comment so it isn't re-attempted.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

src/extraction/tree-sitter.ts

@@ -182,8 +182,12 @@ const MEMBER_ACCESS_TYPES: ReadonlySet<string> = new Set([
  * member-access receiver is reliably a type (not a local/variable). The
  * static-member/value-read pass is gated to these — the ones where it was the
  * confirmed residual frontier (enum-value / static-field reads). TS/JS/Python
- * are deliberately excluded: their coverage was already high and they drive the
- * retrieval-performance benchmark, so there's no need to perturb their graph.
+ * are deliberately excluded, and a measured A/B confirms the call: extending the
+ * pass to them adds ZERO coverage — in import-based languages you must `import` a
+ * type before any `Type.MEMBER` read, so the import edge already covers it (the
+ * static read is pure duplication) — while adding real graph noise (+1813 edges /
+ * +2448 `references` on excalidraw, the retrieval-perf benchmark, all pointing at
+ * already-covered types). Don't re-add `member_expression`/`attribute` here.
  */
 const STATIC_MEMBER_LANGS: ReadonlySet<string> = new Set([
   'java', 'csharp', 'kotlin', 'swift', 'scala', 'dart', 'php', 'cpp',