Keep the expression pass off fork_pointer

[DavidSagan]

A fork_pointer holds a node id, and a node id is a number, so substitute_values — the pass that replaces every evaluable scalar with its value — "evaluated" it too and wrote the result back through format_double, the shortest text that round-trips as a double:

110  →  "%.1g" = 1e+02   → 100 ≠ 110
        "%.2g" = 1.1e+02 → 110 ✓   so the pointer became "1.1e+02"
291  →  "%.3g" = 291                stayed "291"

which is why only some pointers looked wrong: an id has to be a multiple of ten from 100 up to reach exponent form. The value is still numerically right — but every reader parses it with std::stoull, which stops at the . and returns 1.

Three readers, three failures, one message

Reader	Effect of stoull("1.1e+02") == 1
run_element_bookkeeper	fork_seed[1] = def — the destination branch inherits no reference or floor from the Fork
link_fork_from	node 1 is not a map, so continue — the destination silently loses its ForkFromP entry
remap_fork_pointers	1 is not in the provenance map — the one visible symptom, fork_pointer target is outside the expanded lattice

The fix

Add fork_pointer to non_expr_keys(). Its siblings to_line, destination_element, new_branch and propagate_reference were already there; this one was missed because expansion creates it rather than the user writing it, so it never looked like a value the expression pass would see. A node id is not a physics parameter and has no business going through the evaluator — a better place to fix this than making three call sites parse defensively.

The regression test

It reproduces a chained-and-cross-linked fork lattice and asserts no problems, five all-digit pointers, and five ForkFromP groups.

The first version of it passed with the fix reverted: every id happened to land outside the exponent-form range. It now carries three unused pad Drifts that shift the work-tree ids until two of the five destinations land in it. Verified both ways — fails with the fix reverted (lat.problems.count == 0 reports 1), passes with it in. The assertions hold whatever the ids turn out to be; they just stop exercising this particular bug if an unrelated change shifts them again, which the comment says.

153/153.

🤖 Generated with Claude Code