feat(editor): auto-trim empty white margins from results v1.096 User saw a wide blank strip on one side of a receipt scan. Repro with the actual photo: detection is accurate (corner peaks 0.91-0.94, paper edges correct) — the blank is the document's real margin (the table is printed off-center, with only a handwritten note in the empty side). So the crop faithfully includes the paper's empty margin. - New AutoTrim: on the flattened result, estimate content via background- division (shadow-free) then crop only genuinely-empty sides. Safety: a side is trimmed only if its margin >= 8%, capped at 22%, with 2.5% padding kept, and never trims below 50% of either dimension. Faint handwriting counts as content (dark threshold 175, low pixel-count gate), so a side with any marks is preserved — validated in the spike (the note-bearing side measured 0% trim). - Wired into both EditorFlatten (before sharpen, so every filter inherits the tighter frame) and ScanPipeline (batch). - Logged the diagnosis in ENGINEERING_LOG section 8. Constraint: AutoTrim never recycles its input; callers recycle the pre-trim bitmap when the result differs. Content detection is shadow-robust via background division so table borders (dark) are always kept. Confidence: medium-high Scope-risk: module Reversibility: trivial Directive: on-device, confirm the receipt's blank side is trimmed while the handwritten note and signature survive; if a real margin is over-trimmed, raise MIN_BLANK or PAD_FRAC. Tested: assembleDebug + testDebugUnitTest exit=0 (22 tests); python spike on the reported receipt (note-side 0% trim, empty side trimmed). Not-tested: on-device across varied documents. Related: ENGINEERING_LOG section 8 🐙 Autopus