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

[rahlk]

Is your feature request related to a problem? Please describe.

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.

Describe the solution you'd like

• 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

Describe alternatives you've considered

Not stated in the original issue.

Additional context

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.

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.