doctor: detect ctime churn that silently invalidates the stat cache

Split out of #82, where a cron running `chown -R` over the monorepo every 60 s bumped ctime on all 34,515 files, making every first-after-a-pause `update-worktree` legitimately rewrite the whole tree (~4 s instead of ~292 ms). The failure mode generalises — SELinux relabelling, backup agents, security agents setting xattrs all churn ctime behind git's back — and it is invisible: every timing reads as slow I/O, not a stat-cache miss.

`doctor --worktree` should detect it. A naive tree-wide `ctime > mtime` test is a weak signal (plenty of legitimate operations produce that); the precise version is comparing the per-worktree index's *cached* ctime against on-disk ctime for a sample of entries whose mtime and size still match — that combination is the churner's fingerprint. Remedy: `core.trustctime=false` on the server repo (verified in #82: ~4,050 ms → ~292 ms sustained across churn sweeps).

Start with the `doctor --worktree` entry point and the per-worktree index behavior described here, using issue #82 for the observed ctime churn and `core.trustctime=false` result. Determine how to sample entries whose mtime and size still match, compare cached and on-disk ctime, and report the churn with the documented remedy when detected.

Written by the indexing model from the issue text.