Move BOM handling in 4 more files onto formats::text (#905)

[Mikola Lysenko (mikolalysenko)]

LLM Description written by Claude Code:claude-opus-5-5

Refs #905 (step 3, slice 3). This PR doesn't close the issue: 11 files stay on PENDING_INLINE_BOMS, and open PRs change every one of them.

Summary

Four production files still handled a leading UTF-8 BOM with their own inline code. They now call formats::text::{split_bom, strip_bom}, and the guard's pending list drops them.

File	Site	Now
patch/redirect/vlt.rs	vlt.json modifiers probe	strip_bom
vendor/go_mod_edit.rs	normalize_for_read (go.mod / go.work read-only parsers)	strip_bom
vendor/jvm/gradle.rs	append_line (BOM-only file check), first_statement_offset (never insert before a BOM)	strip_bom, split_bom(..).0.len()
vendor/lock_inventory/pypi.rs	parse_pipfile_lock, the shared reader for the inventory, the hosted Pipenv rewriter, upstream restore and discovery	strip_bom (was trim_start_matches)

Why

• Issue: #905. Register row E64 (register). Living document: doc/04-js-lockfiles.md, the E64 bullet.
• Leverage: B 0, U 0, D ≈4 (four inline copies of the one-BOM rule), R L. Score ≈8. It was the top-ranked candidate whose files no open arch-refactor/* or agent/fix-* PR changes.

Behavior

• Files with zero or one leading BOM: no change.
• A Pipfile.lock that starts with two BOMs now fails to parse: the second BOM counts as content, which is the rule every other reader has followed since Move BOM handling in 11 more files onto formats::text (#905) #1160. Before this PR, trim_start_matches dropped both. Consolidate remaining BOM stripping after the pnpm reader failures were fixed #905 asks that any site keeping "any number of BOMs" justify it, and nothing justified it here. The vlt, go.mod and Gradle sites already stripped exactly one BOM, so this is a pure move for them.

Deleted

• Production: 4 inline BOM rules. Diff: +11/−13 production lines, +74 test lines (git diff --stat over the 5 files).

Tests

Each former caller gets a 0/1/2-BOM test:

• vlt::tests::modifiers_probe_reads_past_one_vlt_json_bom_only
• go_mod_edit::tests::normalize_for_read_drops_one_leading_bom_only
• jvm::gradle::tests::appended_and_inserted_lines_skip_one_leading_bom
• lock_inventory::pypi::tests::pipfile_lock_reads_past_one_bom_only. Its two-BOM assertion fails on main, because trim_start_matches parses the lock; it pins the behavior change above.

Results:

• cargo clippy --workspace --all-features -- -D warnings: clean.
• cargo test -p socket-patch-core --lib: 5839 passed and 4 failed. All 4 failures need root, also fail on main in this sandbox, and pass in CI: copy_tree::relax_loop_must_not_traverse_symlinked_root, vlt_heal::an_unremovable_hidden_lock_keeps_every_store_entry, pypi_poetry::wire_write_failure_maps_error_and_leaves_lock_untouched, pypi_requirements::wire_failure_rolls_back_already_written_files.
• CLI suites:
  • e2e_vex_lockfile: 343 passed.
  • e2e_vlt: 27 passed.
  • gradle_agent_cli: 52 passed.
  • in_process_redirect_pipenv: 11 passed.

Risk

Low. The change is mechanical, and only the double-BOM Pipfile.lock case behaves differently.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NRDjSfGgExpXELjwUSeZwi

---

Note

Low Risk
Mechanical refactor with one edge-case behavior change: double-BOM Pipfile.lock files now fail to parse instead of being accepted.

Overview
Continues #905 by routing four call sites through formats::text::{strip_bom, split_bom} instead of ad hoc UTF-8 BOM handling, and removes those paths from PENDING_INLINE_BOMS.

vlt (modifiers probe on vlt.json), go.mod read normalization, Gradle (append_line / first_statement_offset), and Pipfile.lock parsing now share the one leading BOM = encoding rule. vlt, Go, and Gradle behavior is unchanged in practice; Pipfile.lock parsing no longer strips every leading BOM via trim_start_matches—a second leading BOM is treated as content and parse fails, matching other readers.

Each migrated area gets a small test pinning 0/1/2-BOM behavior.

^{Reviewed by Cursor Bugbot for commit 2f5cd77. Configure here.}

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 2f5cd77. Configure here.}

[Mikola Lysenko (mikolalysenko)]

Ready for review at head 2f5cd77e80297c8f8729feaa095ab916da3784ef.

• CI: all check suites on this head are green (no failures; skipped jobs are path-filtered).
• Bugbot: reviewed 2f5cd77e, no findings. No unresolved review threads.
• Mergeable: yes, no conflicts. No CHANGELOG.md change.

Slack announcement: not sent this run (Slack send tool unavailable); the next run will retry.

---

Generated by Claude Code