checkNoDeletedExportsInUse consumer refs also conflate file-level imports-type with symbol-level calls

[carlos-alm]

Context

While fixing #1830 (exports output consumers[] conflating file-level imports-type entries with symbol-level calls entries), I found the same underlying ambiguity in a separate, unrelated code path.

checkNoDeletedExportsInUse in src/features/check.ts runs this query to find external consumers of a to-be-deleted exported symbol:

SELECT DISTINCT caller.name, caller.file, caller.line
FROM edges e
JOIN nodes caller ON e.source_id = caller.id
WHERE e.target_id = ? AND e.kind IN ('calls', 'imports-type') AND caller.file != ?

For imports-type edges, e.source_id is the importing file's node (see emitNamedSymbolEdges in build-edges.ts), so caller.line is always 0 and caller.name equals caller.file. src/presentation/check.ts then renders this as <file>:0 in the CI violation message, e.g.:

Config (interface) — file types.ts deleted but still used by 1 external consumer(s): consumer.ts:0

The fabricated :0 line number is misleading the same way the exports CLI output was before #1830 — it looks like a real call-site line but there's no such line.

Suggested fix

Apply the same fix pattern used for #1830 (add a consumerKind: 'file' | 'symbol' discriminator derived from caller.kind, and have presentation/check.ts render file-level consumers without a fabricated line number) to checkNoDeletedExportsInUse / ConsumerRef in src/features/check.ts and its formatter in src/presentation/check.ts.

Out of scope for #1830 itself since it's a separate feature (CI predicate output), not the exportsData output the issue is scoped to.