[BUG] Search/grep compressor fuses matches into single lines, manufacturing false line↔content associations

Version: headroom-ai 0.37.0 (pipx), macOS arm64 Config: compressor allowlist smart_crusher,code_aware,search,log,tabular, HEADROOM_LOSSLESS=1.

Observed in a real session: grep output for contact_precedence came back fused — matches from different lines run together with content from only the first:

Line 476: settings: settings({contact_precedence: 497: 535: 556: …

Lines 497/535/556 became bare numbers glued into line 476's content, and the matched content from those lines was silently dropped.

Why this is worse than ordinary lossy compression: for line-numbered search output, the line number is the coordinate the agent will act on. Fusing coordinates with the wrong content manufactures false line↔content associations — the model can quote settings({contact_precedence: as living at line 497. Whole-line drop (line numbers listed bare, e.g. matches at: 476, 497, 535, 556) keeps the savings and loses nothing an agent can't re-obtain with one cheap grep.

Request: for line-numbered search/grep output, drop whole lines rather than fusing; never merge a line's content with another line's number. (Confirm whether HEADROOM_LOSSLESS=1 is intended to cover the search compressor's output format — the fused output above occurred with it enabled.)

Context: the client's agent rules treat compressed output as navigation-grade, which contained this incident — but the failure mode silently manufactures exactly the wrong kind of evidence, so it belongs in the compressor's format contract.