Nightly gem e2e red on bundler 1.17/2.1: CRLF source-block rollback unattributable #1997

The nightly CI schedule run on main is red on two e2e-extended gem legs, and nothing open is fixing it.

Evidence

• Run 41585451732 (schedule, 2026-11-03 05:42 UTC, head 3eb2ec1):
  • e2e-extended (ubuntu-latest, e2e_redirect_gem_build e2e_vendor_gem_build, 3.1, 2.1.4), job 125750207261
  • e2e-extended (ubuntu-latest, e2e_redirect_gem_build e2e_vendor_gem_build, 3.1, 1.17.3), job 125750207277
• Both fail only in gem_hosted_redirect_keeps_a_crlf_gemfile_crlf, in the crlf-gemfile-source-block arm (e2e_redirect_gem_build.rs:4852). Rollback exits 1 with hosted_wiring_contested / patched_ref_unattributable: "GEM section lists 2 remotes (a merged multi-source lock), and no gem in it is source-pinned to Socket patch … by both DEPENDENCIES (!) and a Gemfile source … do block".
• The failure is deterministic. The arm was added in Sweep cli/src/ui: inline wrappers, fix fake tests #1961, and PR CI runs only the bundler 4.0.21 leg, so only the nightly hits it.
• The other red leg in that run, test (windows-latest, 1) (hosted_scan_without_a_python_lock_warns_no_lockfile), is fixed on main by Fix Windows PyPI no-lockfile hosted scan test #1994.

Status

#1995 added the same bundler >= 2.2 floor that gem_hosted_unwind_keeps_a_source_block_bang has. It was closed unmerged on 2026-11-03 15:06 UTC with no comment, so the CI janitor treats that approach as rejected and isn't retrying it. There are two ways forward:

1. Product fix: teach the Gemfile attribution reader (crates/socket-patch-core/src/vex/discover/gem.rs) to attribute a gem inside a nested source … do block on a merged pre-2.2 lock, so rollback works on bundler 1.17/2.1.
2. Reopen Fix nightly gem e2e red on bundler 1.17/2.1 CRLF arm #1995 (test-only era floor).

Until one of them lands, the nightly stays red on these two legs.

Generated by Claude Code