edges/: E-class dedup batch (start with the 27 open-coded copies of add_edges_from_ids)

[nikolay-e]

Shelved deliberately from the 2026-08-20 cleanliness pass: these are verified
and output-neutral, but their only net is the 2725-case corpus, so landing them
together with anything else makes a regression un-bisectable. One commit per
item, corpus run per commit.

Do F1 first — it is pure deletion with no new API. base::add_edges_from_ids
(edges/base.rs:242-254) already exists, and 27 sites open-code its exact
5-line body. In 9 files the same function both calls the helper and hand-rolls
it: swift.rs calls it at :106 and :111, then inlines it at :120-124;
erlang.rs calls at :100/:105, inlines at :111 and :123. ≈ −108.

Then, in rough value order:

item	what	Δ
F2	24 Lazy<FxHashSet<&str>> keyword tables spanning 796 lines — rustfmt puts one literal per line. A 3-line fn kw(s) { s.split_ascii_whitespace().collect() } collapses each to 3-6. Verified order-insensitive: every one of these statics is only ever .contains(...), never iterated	≈ −600
F4	the identical single-capture regex extractor, 37 as 7-line fns + 24 inline	−225
F3	the "simple" discover_related_files shape, 22 sites of 19-22 lines; ruby.rs:120-138 and lua.rs:121-139 are character-identical except the rb_/lua_ prefix	−220
F5b	16 copies of a 9-line lowercase-index build	−128
F5a/c	23x 7-line frags prelude, 6x byte-identical 12-line identifiers fallback	−125
F6	28x the same file_stem -> lowercase chain; sibling.rs:38-43 is a 6-line pass-through called once	−56

Hard constraint a reader cannot see, and the reason this is not a
table-driven rewrite. edges/mod.rs:260-311 caps candidates with a
per-builder top-K, and category_entries (:222-232) takes the category
from the first builder in registration order that emitted the pair.
Therefore: merging any of the 37 semantic builders, or reordering
semantic/mod.rs:42-80, changes cap granularity and the category winner — that
is Q-class and frozen during an evaluation cycle. These 35 per-language files
may share helpers; they may not be unified into one builder.

Explicitly rejected, so nobody re-searches: the 269 Lazy<Regex> statics are
genuinely distinct pattern data, and the six large discover_related_files
bodies (javascript.rs:304-436, rust_lang.rs:431-529, go.rs:297-383,
python.rs:299-383, c_family.rs:393-476, jvm.rs:782-856) implement
different multi-hop algorithms sharing only a 5-line preamble.

Gate per commit: scripts/bitcheck.sh record/check (24 cells) plus the
full corpus — bitcheck runs against this repo (Rust/Python/YAML/MD/TOML) and is
structurally blind to the Scala/Swift/Haskell/Dart/Erlang tables these items
touch.

Protocol: ANALYSIS_code_cleanliness_refactoring.md §4 + R2.2 rows 9, 27, 31.

[nikolay-e]

Partly done in 684538a (net −2508 across 46 files, corpus 2902/2902, bitcheck 24/24).

Landed:

• F1 — 50 sites open-coded base::add_edges_from_ids; all 50 now call it, and
  18 files stopped needing the add_edge import. One site was correctly rejected
  by the compiler and keeps its loop: link_by_path_match iterates
  Vec<&FragmentId>, not owned ids, and now says so in one line.
• F2 — 28 keyword tables (not 24; 880 lines) collapsed via a new
  base::kw(list) that splits one whitespace-separated string. Verified before
  touching them: every one of the 28 is only ever .contains(...), never
  iterated, so nothing observes the literal layout.
• F4 — 97 sites (not 61) of the single-capture regex extractor now call
  base::captures1(&RE, content). The audits claim of "37 as 7-line fns" was
  wrong: there was exactly one whole-function form, the rest were inline, so
  the real saving is ~152 lines, not 225.

Still open (F3, F5, F6), with corrected numbers:

• F3 — the 22-site discover_related_files "simple" shape, incl. the
  character-identical ruby.rs:120-138 / lua.rs:121-139 pair. Untouched.
• F5b/F5a/c — the lowercase-index build and the frags prelude. Untouched.
• F6 is over-counted: 12 file_stem() chains in edges/, not 28, and they
  split into a .to_string() and a .to_lowercase() variant, so the ceiling is
  ≈ −20. Low priority.

C1 respected throughout: no builder merged, semantic/mod.rs:42-80 untouched, so
per-builder cap granularity and registration-order category assignment are
unchanged.