fix(scanner): resolve scan roots to absolute paths

[Muawiya-contact]

Closes #103.

What & why

Rules anchored at the filesystem root — /tmp/**, /var/log/** — are
anchored deliberately: that is what keeps /tmp out of
~/tmp/tax-return.pdf (#41). But jwalk builds every entry's path from
the root as it was handed in, so a relative root produced entries no
anchored pattern could match:

$ diskern scan /var/tmp --top 2
Reclaimable: 3.0 MB across 1 finding and 0 duplicate sets.
       3.0 MB  /var/tmp/build-9a2f/out.o
               matched rule temp-dirs: Temporary files...

$ cd /var && diskern scan tmp --top 2
Scanned 1 files.
Reclaimable: 0 B across 0 findings and 0 duplicate sets.

The walk found the file; the rules could not tell where it was. That is
a plausible-looking empty result rather than an error — the #82 failure
arriving by a different route, and worse under --json, where nothing
says the paths were relative.

Roots are now resolved in scanner::scan, so the CLI and the desktop
app both get it.

absolute(), not canonicalize(). No filesystem access, works on a
path that does not exist, and leaves symlinks alone — canonicalize
would rewrite /var/tmp to /private/var/tmp on macOS and scan
somewhere other than what was asked for. It leaves .. in place,
because a/../b is only b when a is not a symlink; that limit is
documented beside the code rather than papered over.

Side effect worth naming: every path the scanner yields is now
absolute, which settles the open question in #103 about
actions::quarantine recording a file's original location. A relative
original could not have been restored from a different working
directory.

Tests

• scanner.rs: absolute_root resolves a relative root and leaves an
  absolute one untouched, including /var/tmp.
• crates/diskern-cli/tests/relative_root.rs: drives the real binary
  with current_dir and . as the root, using a root-anchored rule.
  Changing the process working directory inside a test would race the
  other tests in the same binary, so this uses a child process instead.
  Unix only — a /-anchored pattern cannot match c:/... on Windows,
  so neither can the bug.

Verified against the unfixed scanner: the relative case fails, the
absolute control passes. A regression test that passes without the fix
is not one.

Validation

• cargo fmt --all
• cargo clippy -p diskern-core -p diskern-cli --all-targets -- -D warnings
• cargo test -p diskern-core -p diskern-cli — 70 pass, 0 fail

Checklist

• cargo fmt --all and the required core/CLI clippy validation are clean
• The required core/CLI test suite passes
• Commits are small and focused (one logical change each)
• Doesn't weaken a safety principle (read-only scans, quarantine over deletion, deterministic verdicts)

---

Update. Two follow-ups from a self-review, each its own commit:

• The new test file gated every item with #[cfg(unix)] but not its
  imports, so on Windows all four were unused. CI missed it — clippy
  runs on ubuntu, and the Windows test job treats them as warnings —
  but a Windows contributor running the clippy line CONTRIBUTING asks
  for would have got four errors from a file they had not touched. The
  file is gated at module level now.
• Making roots absolute brought them into range of the exclude list,
  which is correct, but the walk then dropped every entry and returned
  an empty report. $XDG_RUNTIME_DIR lives under the /run exclude
  and holds real caches, so a scan there came back looking like a clean
  disk. That is the same wrong answer as diskern scan reports a clean, empty result for a path that doesn't exist #82 and Anchored rules never match when the scan root is relative #103, so the scan now
  names the exclude instead of reporting nothing.

[Muawiya-contact]

ok