follow-up: document or discriminate file-level vs symbol-level consumer entries in exports output

[carlos-alm]

Deferred from PR #1814 review.

Original reviewer comment: #1814 (comment)

Context: PR #1814 makes emitTypeOnlySymbolEdges credit import type { X } statements as consumers of X, using the importing file node as the edge source (since the import statement, not a specific function, references the type). As a result, consumers[] entries for imports-type edges carry file-level attributes — { name: "consumer.ts", file: "consumer.ts", line: 0 } — instead of a caller function's name and call-site line, which is what every other edge kind (calls, constructs) returns.

This is structurally correct (there is no function to attribute the reference to), but any CLI renderer or JSON consumer that treats consumers[].name as "caller symbol" or line as a clickable source location will produce misleading output, e.g. consumer.ts (consumer.ts:0) instead of someFunction (consumer.ts:42).

Greptile suggested either documenting this shape difference in the public output contract, or adding a consumerKind: 'file' | 'symbol' discriminator field to consumers[] entries so downstream renderers can adapt. Both options affect the public exportsData output shape (consumed by the CLI, MCP tools, and any JSON/programmatic consumers) and warrant a deliberate design decision rather than a same-PR fix — out of scope for #1814, which is scoped to the resolution-layer fix.

Suggested next step: decide between (a) a docs-only note on the existing shape, or (b) a consumerKind discriminator field, then implement in src/domain/analysis/exports.ts (exportsData) and any presentation layers that format consumers[].