checker: intermittent invalid memory access in the parallel checker (cached_expr_type_ref) during v up self-compilation

Environment

• Windows 10 x64, TCC-built compiler (-compile-backend fastc -gc none -nocache self-build via makev.bat)
• Commit: c4e254fab1 (markused: keep implementers of interfaces dispatched from cached modules (#31004))
• Trigger: plain v up (which runs v self)

Observed

v up (and the self-build it kicks off) crashed once with:

0x7ffeb406b8cf: at ???: RUNTIME ERROR: invalid memory access
src.c:29147: by types__TypeChecker__cached_expr_type_ref
src.c:129: by types__TypeChecker__resolve_type_nonliteral
src.c:1475: by types__TypeChecker__resolve_type_uncached
src.c:1426: by types__TypeChecker__resolve_type_slow
src.c:65451: by types__TypeChecker__resolve_type
src.c:3141: by types__TypeChecker__selected_file_receiver_method_name
src.c:3049: by types__TypeChecker__selected_file_call_base_name
src.c:3069: by types__TypeChecker__selected_file_call_name
src.c:4150: by types__TypeChecker__collect_selected_file_node_called_fns
src.c:4189: by types__TypeChecker__collect_selected_file_node_called_fns
src.c:3936: by types__TypeChecker__collect_selected_file_fn_body_called_fns
src.c:4228: by types__TypeChecker__collect_selected_file_root_called_fns
src.c:3734: by types__TypeChecker__collect_selected_file_called_fns_walk_parallel
src.c:3626: by types__TypeChecker__collect_selected_file_called_fns
src.c:59647: by types__TypeChecker__check_semantics_parallel
src.c:59630: by types__TypeChecker__check_semantics_opt

The file list shows the crash is inside the parallel semantics pass, in the call-collection walk (collect_selected_file_called_fns*), resolving a callee type from cached_expr_type_ref.

What I checked

• Not reproduced afterwards on the same host:
  • a rebuilt compiler at cf3d560a56 ran v up cleanly twice;
  • four stress self-compiles (v -nocache -gc none -o ... cmd/v) all passed;
  • building cmd/tools/vup.v with the c4e254fab1-era compiler logic rebuilt by the current compiler also passed, as did a plain v self at c4e254fab1.
• So this is intermittent; I could not isolate a deterministic input.
• Reviewed cached_expr_type_ref (vlib/v/types/checker.v) plus its callers: expr_type_set/expr_type_values are grown in lockstep everywhere I could find, so the guarded dense reads look consistent; the singular crash is more consistent with a cross-worker race in the parallel path than with an OOB on a missing grow. Not proven, just what inspection showed.

Relation to closed issues

The intermittent parallel-checker crash family (#29122, #28924, #28897) is closed; this stack (selected_file_call_name -> resolve_type -> cached_expr_type_ref) does not match any of their traces, and no open issue or PR mentions cached_expr_type_ref, selected_file_call_name, or collect_selected_file_called_fns.

Not verified

• Linux/macOS: not tested.
• Whether -no-parallel avoids it: not observed long enough for the crash to recur.