[kingchenc]

With --max-depth, folders at the limit were listed but never read, and the
scan still reported them as 0 B: an unread target/debug/incremental of 210 GB
looked empty. The same happened in the app's "Max depth" setting.

• Core: every tree node records whether its own listing was read; a folder
  is complete when it and everything below it was. DirSize and ScanReport
  carry complete (in JSON only when false), ScanTree::complete() says
  whether the whole scan is exact. A cancelled walk is never complete.
  Removing the only unread folders from a tree makes it exact again.
• CLI scan: an unread folder reads ? <path> (not measured), a partly
  read one ≥ 1.2 GB; the totals carry ≥ and a DEPTH LIMIT line says
  why. --save and --since refuse --max-depth (a snapshot or comparison of
  a partial scan would report every skipped folder as emptied), and
  --max-depth 0 is refused (the engines disagreed on what it meant).
• Snapshots: unread folders are stored as their own entry kind and a
  partial scan sets a header flag, so the tree the elevated MFT helper
  hands back keeps the marks. Older readers take both for an ordinary
  folder. diff() refuses partial snapshots.
• App: unread folders show "nicht gemessen" / "not measured" (table, map,
  tooltips, biggest-folder card), partly read ones ≥; the view says that
  the depth limit was hit. Such a scan is neither stored as a snapshot nor
  compared (as with a cancelled one).
• README documents --max-depth and the JSON field.

Tests: 1 new core test (depth 1/2/3/4, snapshot round trip, diff refused,
removal), 2 new CLI tests (human and JSON output at depth 1/2/3; --save,
--since and --max-depth 0 refused), 1 new UI helper test. Each of 13
mutations of the new logic is caught by a test.