fix: add dual id generators to reduce snapshot churn

[kgutwin]

Partial resolution of #6152.

@prql-bot pointed out that the majority of the snapshot churn when working on PRs that affect std.prql or other bits of the resolver was actually down to the node IDs that are generated during the pass through the semantic resolver. This PR takes a novel approach to reducing this churn by splitting the usize ID space into two parts: calling id.gen_sys() returns an ID above 4 billion, while leaving the original call id.gen() as-is. On a 32-bit machine, this would leave 294 million IDs available for "internal" node IDs, and 4 billion for "user" node IDs. On a 64-bit machine, the "user" node space stays the same size and the "internal" node space is... big 😄

The intent behind this split is so that the node IDs that normally show up in any given snapshot are essentially normalized to the query that they represent, distinct from any IDs that result from parsing internal libraries such as std.prql.

In my testing, changes to std.prql will result in far fewer snapshot changes. It's not totally eliminated, and the span issue originally flagged in #6152 remains (to be fixed in a separate PR), but it's far more kind to code review.

[prql-bot]

The approach holds up — I checked it empirically rather than just reading it. Appending a function to std.prql and rebuilding leaves prqlc debug lineage output byte-identical for from invoices | derive t = (total | math.round 2) | group customer_id (aggregate {s = sum total}), and no gen_sys id (>= 4e9) leaks into any user-visible lineage output or snapshot in the tree. cargo test -p prqlc passes locally. Also worth noting for anyone reading the commit-by-commit diff: the span: "0:1699-1701" -> "0:1732-1734" shifts in the first commit (which look like they were generated against #6155's std.prql) are reverted by the second, so the net diff is clean.

Two points that don't fit as inline suggestions:

source_id == 0 is a bare magic number in both new call sites, and semantic/mod.rs separately passes a bare 0 to parse_source(std_source, 0). A pub const STD_LIB_SOURCE_ID: u16 = 0; alongside load_std_lib would tie the three together and document the "user sources start at 1" invariant that SourceTree::single/SourceTree::new depend on. I kept it out of the inline suggestions so they apply cleanly on their own — I'm happy to push a commit adding the const and wiring up all three sites if you'd like it.

Nothing fails if the split is later dropped. The 3000-line snapshot diff is the evidence that it works today, but a future refactor that removed the dispatch would just churn the snapshots again and get --accepted. A test that resolves a query using a few std functions and asserts the ids in the resulting lineage are all < SYS_ID_START would lock the invariant in where the snapshots can't.

[prql-bot]

strict_add is the reason test-rust (wasm32-unknown-unknown) is red, and it will take check-ok-to-merge down with it. It stabilized in Rust 1.91.0, but the workspace MSRV is 1.81.0 (Cargo.toml, rust-version), so clippy::incompatible_msrv fires — and test-rust.yaml passes -- -D warnings to clippy, which turns that warning into a hard failure. Nothing wasm-specific about it; the x86_64 leg would hit the same thing (it was cancelled before reaching the clippy step this time), and the nightly test-msrv job would fail on main after merge too.

checked_add(1).expect(..) is stable since 1.0 and keeps the panic-on-overflow semantics you wanted. I verified the suggestion below with cargo clippy --target wasm32-unknown-unknown -p prqlc --all-targets --no-default-features -- -D warnings, which exits clean with it applied.

The rest of the incremental diff reads well — STD_LIB_SOURCE_ID ties the three call sites together, and pointing parse_source(std_source, ..) at the same const is exactly the invariant the two new SourceTree comments describe.