CBM Lens renders a .tsx file as its .css sibling (extension-less qn collision) + File-node snippets silently capped at 51 lines #2791

Two independent reader bugs on v0.12.1 (latest, macOS arm64), large TS monorepo (26k nodes), healthy index (parse_unusable: 0).

1) A .tsx file renders as its .css sibling

Data layer is fine when the qn keeps its extension (...index.tsx.__file__ vs ...index.css.__file__ return the correct source for each).

The breakage is the reader's fallback path:

• The indexer creates only ONE Module node per same-stem group, assigned to the CSS file, with the extension stripped:
  • MATCH (n:Module) WHERE n.file_path = ".../LogoTitleView/index.css" -> 1 row, qn = P.cake.src.component.LogoTitleView.index
  • MATCH (n:Module) WHERE n.file_path = ".../LogoTitleView/index.tsx" -> 0 rows
• On a miss, the reader falls back to the File node and derives the qn by stripping .__file__ and then the last dotted segment:
  ...LogoTitleView.index.tsx.__file__ -> ...LogoTitleView.index.tsx -> ...LogoTitleView.index
• That equals the CSS Module qn, so the fetch returns the wrong node:

$ cli get_code_snippet --qualified-name "P.cake.src.component.LogoTitleView.index" --source-mode full
label: Module
file_path: .../LogoTitleView/index.css   # requested index.tsx

Result: clicking index.tsx shows CSS; clicking index.css shows CSS; both panes look identical.

Scale here: 1036 .tsx File nodes, only 250 have their own Module node; 783 .tsx files share a stem with a CSS Module node and render the wrong content.

Expected: fallback should keep the extension (strip only .__file__), and/or don't collapse different-language files into one extension-less Module qn.

2) File-node snippets silently cap at 51 lines

• ...BtnFood/index.css.__file__ (215 lines) -> 51 lines returned, end_line: 51, next_start_line: null, source_truncated: null
• ...ratings/src/index.tsx.__file__ (466 lines) -> 51 lines, same
• ...LogoTitleView/index.css.__file__ (19 lines) -> full content but end_line: 51 (wrong metadata)

File nodes store start_line/end_line = 0/0, so 51 looks like a server-side default window. With no continuation marker the reader cannot page and shows no truncation notice.

Expected: return full source, or set next_start_line / source_truncated + truthful original_end_line.

Workaround: use symbol-level nodes (they keep the real qn) and read whole files from disk beyond 51 lines.