[filemigrate] Orphaned staging entries accumulate with no cleanup or monitoring path

[charles-fineman]

Context:
Identified during peer review of PR #464 (review of Codex comment #464 (comment)).

Description:
filemigrate failure paths deliberately never remove unverified .grizzle-staging-* entries by name (removal-by-name after a failed identity check could delete a replacement installed by a raced writer). Discovery skips these reserved names, so correctness is preserved — but every interrupted or raced CreateArtifact run now leaves a permanent entry in the migrations root:

• Leftovers accumulate indefinitely; there is no cleanup tool, documented operator procedure, or diagnostic surfacing them.
• Raw directory entries are counted against MaxArtifactDirEntries (default 50,000) before the reserved-name filter in ListArtifacts, so sustained accumulation eventually fails discovery for the entire root with resource_limit even though none of the counted entries are artifacts.

Possible directions (to be designed): a Diagnostic warning when reserved leftovers are observed during discovery, an explicit opt-in cleanup command that safely reclaims verified-stale staging entries, and/or excluding reserved names from the MaxArtifactDirEntries budget.

Why deferred:
Requires new capability (operator cleanup/monitoring surface) outside the footprint of PR #464, which is scoped to eliminating no-follow TOCTOU windows.

Reference:

• Original PR: fix(filemigrate): eliminate no-follow TOCTOU windows #464
• Review comment: fix(filemigrate): eliminate no-follow TOCTOU windows #464 (comment)

Acceptance Criteria:

• Operators can observe leftover reserved staging entries (diagnostic or command output)
• A documented, safe reclamation path exists for stale staging entries
• Decision recorded on whether reserved names count toward MaxArtifactDirEntries