GeezerVison

buildReplacementLines' inserted branch inherited cLead from an
arbitrarily-picked paired content line, so a 4sp LLM search
inserting into a tab-indented or 2sp-indented file emitted the
wrong indent depth. The bug fires on every wrap-in-block,
single-to-multi expansion, or insert-new-block edit where the
caller's search/replace whitespace unit differs from the file's.

Scoped fix:

- detectIndentUnit(lines) scans leading whitespace and returns the
  smallest consistent unit (one tab, or N spaces via GCD). Mixed
  tab+space samples return ("", false).
- translateIndentLevel(rLead, sLead, cLead, searchUnit, fileUnit)
  computes the caller's rep_level relative to their search_base and
  emits the same relative level in the file's unit.
- buildReplacementLines computes searchUnit (from search+rep) and
  fileUnit (from matched) once per splice. Inserted lines (rMid
  non-empty, no search pair) call translateIndentLevel and fall
  back to the previous cLead-inheritance path when detection fails
  or a lead is not a clean multiple of its unit.

Pinned contracts (escape hatch, caller-agrees-with-itself,
empty-body carve-out, ending normalization) all stay green: only
the inserted branch changes, and paired lines take neither of the
new helpers.

Flips the 5 reds in TestEditFiles_FuzzyIndent_InsertionLevelAware
from red to green. Lock #7 and #8 update their expected outputs
to reflect partial post-fix correctness (inserted-line bugs
fixed, middle-substitution leakage still present for follow-up).
Lock #6 (Unwrap) and TestEditFiles_ReplaceAll_FuzzyIndentGap are
middle-substitution cases unchanged by this fix.

Addresses DEREM-11 (diff-aligned pairing known-limitation) for
the pure-insertion class. Middle-substitution level-awareness
remains a separate follow-up tracked by the middle-rewrite locks.