Fix call mismatch poisoning across try suffixes

[lukewilliamboswell]

Summary

• keep rejected call relations from poisoning shared producer type graphs
• propagate erroneous match conditions to explicit runtime-error matches
• add an issue missing a ? after a failable function causes segfault #10456 CLI regression and update the affected snapshots
• add the missing x64win target to the recently added issue Panic: on an unannotated closure in a record literal #10403 fixture so Windows harness CI can execute it

Closes #10456.

Root cause

Ordinary call-argument mismatch recovery merged the expected and actual roots into the error type. For a monomorphic local, the actual root was shared with its producer, so the valid producer call was retroactively left with an erroneous checked type. The match desugared from the try suffix also did not inherit the condition's error marker, leaving postcheck to lower an ordinary match around a condition with no valid checked type.

The call relation now runs in a commit probe: successful relations keep their mutations, while rejected relations roll back completely and report the mismatch from the pristine expected and actual types. Only the rejected call is marked erroneous. Matches explicitly inherit an erroneous condition, preserving the checked-to-postcheck boundary.

CI follow-up

The first PR run exposed a baseline Windows failure in the issue #10403 fixture: its platform declared Linux and Apple targets but no x64win target. Adding that explicit target fixes the Windows harness configuration. PR #10452 contains the same fixture correction; its red run was an unrelated timeout in the JSON optional-fields test, not a failure of the target fix.

Verification

• focused issue missing a ? after a failable function causes segfault #10456 CLI regression
• exact reported basic-cli reproduction
• x64win cross-target build of the issue Panic: on an unannotated closure in a record literal #10403 fixture
• check snapshots
• local full MiniCI: all 73 phases passed across the required targeted snapshot rerun and resumed run
• GitHub CI: all 19 checks passed, including Ubuntu full and Windows harness

[jaredramirez]

I'm not sure about this:

1. I worry that introducing a probe on a hot path will negatively impact perf
2. I don't follow why we shouldn't be commiting unify failures to the types store, that feels wrong to me (but i have not deeply understood the root cause here)

Is the segfault from the issue coming from Check?