fix(core): defer the mtime-granularity probe off the first scan

The FS mtime-granularity write-stat probe ran inline on a source's FIRST
scan. That first scan is the source's initial backup cycle, where every file
is new and each path's first upload must commit its file_state row cleanly.
The probe's stat/sleep I/O (up to ~2.2s on a coarse FS) plus temp-file churn
in the source root added latency/contention to that hot path; on the
windows-latest hermetic chaos runner it tipped a pre-existing
create-during-upload race - the executor's SkipPostUpload on a CREATE leaves
a live orphan object the once-per-boot reconcile never adopts mid-run - into
a duplicate upload, failing the `frequent-edits` scenario ("expected exactly
1 object after edit soak, found 2"). The underlying orphan race is pre-existing
and tracked separately (#144).

Defer the probe: the first scan (no completed scan yet -> last_full_scan_at
is None) trusts mtime with no probe and no coarse fallback, persisting
nothing; the probe runs on the next scan, once a completed scan exists. This
mirrors the existing probe-failure degradation ("trust mtime this cycle,
re-probe next") and costs at most a one-cycle delay before the coarse
fallback first engages on a coarse FS (DESIGN s5.2). Adds a scanner-level
regression test that scan #1 performs no probe and no coarse-fallback re-hash
(and that the probe runs from scan #2).

Also rebases onto origin/main (#142 shared-drive, #143 adaptive parallelism)
and renumbers the migration 0009_mtime_granularity.sql ->
0012_mtime_granularity.sql (contiguous above the applied 0011; sqlx
auto-discovers by filename). Regenerates the .sqlx query cache for the merged
backup_sources INSERTs that now carry both drive_id and mtime_granularity_ns.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QZQVP2tUuTLh8oL31D8heC

Author: pmaxhogan