81% of diagnostics point at 0:0, so the span in the message locates nothing

Across the fail-tier corpus:

diagnostics carrying a rendered span: 113
of those at 0:0:                       91

81% of the spans a user is shown point at line 0, column 0 — a position no source file has. The diagnostic machinery is fine; the spans reaching it are Span::default().

Where they come from

Two distinct sources, worth separating before anyone starts:

1. Literals are constructed span-less. NumberExpr is built with Span::default() at the parser's number sites (src/parser/expr.rs:892, :897), so any rule reporting against a literal has nothing to point at. This is what makes E3019 (match arm literal out of range) name the literal in its text but locate it at 0:0 — the text is doing the work the span should.
2. Call sites carry no span. E6001 (requires topology '…', but is called from '…') renders 0:0 even though FunctionCallExpr has a span field, so somewhere between parse and report it is default.

There is also a third class that does not reach the span machinery at all: several errors are pushed as bare strings with no code and no span (Error: Cross-topology access error: …), which renders with no position at all rather than a wrong one.

Why it matters for a release

A span that says 0:0 is worse than no span: an IDE or an LSP client will happily jump the cursor to the top of the file. It also defeats the fix-it hints, which carry the same span — the W1001 "prefix with underscore" suggestion currently proposes an edit at 0:0.

Suggested order

The parser fix is the broad one and probably reclaims most of the 91. Worth measuring the same two numbers after it, since the remainder will point at whichever rules synthesize expressions rather than reading them from source.

Found while fixing Vx#334 / Vx#431. Related: Vx#448 (the same messages print internal Debug output).

Start in src/parser/expr.rs at the NumberExpr construction sites around lines 892 and 897, then trace FunctionCallExpr spans through diagnostic reporting for E3019 and E6001. Compare the fail-tier corpus counts before and after the changes, and inspect the bare-string errors separately. Done means diagnostics and related fix-it hints no longer use 0:0 when a source span is available.