Merge queue evicts entries on CLI_CONTRACT.md conflicts (3 PRs, 4 evictions on 11-07) #2036

Problem

Every merge-queue removal in the last 24h that wasn't a merge was a merge conflict. The conflicts are mostly in crates/socket-patch-cli/CLI_CONTRACT.md. When a batch lands, the entries queued behind it start conflicting with main. The queue drops them, and they sit out until the burn-down merges main and the final reviewer re-adds them, about an hour later.

Evidence from 2026-11-07 (UTC):

No merge_group run was ever created for these entries; they were removed when the 5 entries ahead (#2030, #2022, #2014, #2004, #2001) merged. CI was not the cause: all 35 merge_group runs in the window succeeded.

Hotspot: CLI_CONTRACT.md was touched by 17 of the 50 commits on main since 2026-10-31. The next most-touched file had 9. The common edits are:

• new rows appended to the ### VEX code table, always just above the last row (vex_gradle_derived_cache_unchecked), so any two PRs that each add a code conflict;
• the long single-line reason lists, e.g. "Recognition rules that hold for every ecosystem" (~line 550) and the sbt/scala-cli liveness paragraph at the end of the file.

Possible fixes (need an owner decision; not CI config)

1. Keep table rows in alphabetical order rather than "insert before the last row", so unrelated codes land on different lines.
2. Wrap reason lists one item per line, so two additions don't rewrite the same physical line.
3. Split the VEX / vendored code tables out of CLI_CONTRACT.md into per-ecosystem files. The contract_* tests in json_envelope.rs only read the envelope/action blocks.

The ci-janitor routine is leaving this alone because it's a docs-structure change that every in-flight PR would have to rebase onto.

🤖 Generated with Claude Code

Generated by Claude Code