Hosted Go scan in a go.work member pins a version another member outranks #1753

[agent] Follow-up split out of #1751 / #1752.

#1752 makes the shared Go version gate (go_build_list::project_selection) read every go.work use member's go.mod and go.sum, so agent apply, apply --check, vendor and vex see when another member requires a newer version of the patched module. Since vex covers hosted pins too, a hosted replace that the workspace ignores is no longer attested.

The hosted write gate is still single-module. rewrite_golang (crates/socket-patch-core/src/patch/redirect/mod.rs, the go_build_list::select call) is an in-memory rewriter. It sees only the root go.mod/go.sum the hosted engine reads, so scan --mode hosted in member a still writes replace example.com/upstream v1.0.0 => patch.socket.dev/gopatch/... when member b requires v1.1.0, and reports it as redirected. vex then leaves it out (go_version_not_selected), but the scan result still claims a patch the build doesn't link.

Expected: hosted scan should skip that dep with redirect_golang_version_mismatch, the same as when the module's own go.mod requires another version. One option is to pass the go.work members' go.mod/go.sum texts into the hosted read set, or to pre-filter golang candidates in scan/hosted.rs through project_selection.

Repro: the #1751 workspace (member a on v1.0.0, member b on v1.1.0), then scan --mode hosted in a with a v1.0.0 hosted grant.

Generated by Claude Code