deploy: a host whose sync_deletions marker came from an empty shallow bootstrap never re-bootstraps #16787

Problem

#16310 fixed the root cause of a bad bootstrap (ansible/playbooks/update-all-nodes.yml's pre-flight code_source checkout cloned with depth: 1, so services/sync_deletions.py::compute_bootstrap_plan's git log --diff-filter=AR only ever saw the one commit a shallow fetch kept, silently under-reporting what to delete) and added a guard (_is_shallow_repository) that now refuses to compute a bootstrap plan at all on a shallow clone, going forward.

That guard cannot help a host that already ran the bad bootstrap before this fix landed: services/deploy_artifacts.SYNC_DELETIONS_MARKER (.autobot_sync_deletions_commit) is just a commit SHA on the target. Once written, ansible/roles/_shared/tasks/sync_deletions.yml always takes the cheaper compute_deletion_plan (diff-mode) path from then on — there is currently no way to tell "this marker came from a good bootstrap" from "this marker came from an empty, shallow one", so an already-affected host stays permanently missing every file that should have been deleted before that first (bad) bootstrap's commit, and nothing about its current state signals the gap.

Why this is a separate issue

#16310's own acceptance criteria named this ("hosts that already hold a marker from an empty shallow bootstrap" need to re-run bootstrap too), but fixing it needs either new on-disk marker metadata (recording whether the bootstrap that produced a given marker ran on a full-depth clone) or a one-time out-of-band remediation across the fleet, either of which is a distinct, riskier change from the root-cause fix and worth its own design/review pass rather than folding into that PR.

Acceptance criteria

• A way to tell, for a target already holding .autobot_sync_deletions_commit, whether the bootstrap that wrote it ran against a shallow or full-depth clone.
• A host in the "bad" state re-runs compute_bootstrap_plan (not compute_deletion_plan) exactly once, then behaves like any other host from then on.
• Test: a target whose marker predates this fix, on a fixture repo, ends up planning the deletions a correct bootstrap would have found.
• Host evidence: a real maintainer install that has this marker today drops to 0 "removed_from_source" entries in the /code-sync/drift/full report after the remediation runs.

Relates to #16310.