Artifact text: drop the byte cap and text_truncated, to match typescript #172

Problem

Artifact text is captured under a byte cap (262144 by default), and a text_truncated flag marks
the files that were clipped. codeanalyzer-typescript has removed both: source is now the whole
file, or "" under --no-artifact-text. This issue is to decide whether to match, so the three
analyzers agree on what source means.

The argument for removing it:

• A truncated source reads exactly like a complete small file. Nothing about the value says
  it is a prefix, so every consumer must carry the flag alongside it to know whether the text can
  be trusted. Miss that, and you are silently reasoning about the first 256 KB of a file.
• The flag cannot even carry that meaning cleanly. text_truncated: false covers two different
  states: "this is the whole file" and "text capture is off, source is empty". A consumer
  checking only the flag cannot distinguish them.
• It buys very little. Measured on microsoft/vscode: 32 of 4,953 artifacts exceeded the cap —
  0.6%. The payload saving is negligible against the interpretation cost.
• Hash and size were always full-file regardless, so integrity checks never depended on the cap.

Scope boundary

The artifact-text byte cap, its CLI flag, and the text_truncated field, in both analysis.json
and the Neo4j :Artifact node. Not in scope: --no-artifact-text (or its equivalent), which stays
as the way to opt out of the payload entirely — that is a real choice with an unambiguous meaning.

Goals

• Decide whether to match typescript's removal, or keep the cap and have typescript restore it
• If removing: drop the cap, the flag, and the CLI option; source becomes whole-file-or-empty
• Update the Neo4j contract and any consumer docs describing text_truncated

Caveats and known risks

• Breaking either way. Removing text_truncated changes the emitted shape; keeping it while
  typescript drops it means a consumer reading the neutral :Artifact node gets the field from one
  analyzer and not another — the same divergence that made typescript put source on the graph in
  the first place (it had been omitted there while python emitted it).
• Uncapped capture means a repository with very large checked-in files produces a
  correspondingly larger payload. vscode suggests this is rare, but it is unbounded in principle.
• The three analyzers should land on the same answer. If the cap is worth keeping, typescript's
  removal is the change that should be reverted, not this one adopted.

Definition of done

All analyzers agree on what an artifact's source means: whole file, or empty because capture was
disabled — with no third "prefix" state — or a documented, deliberate decision to keep the cap
everywhere.