Add a per-file staleness check before committing accumulated WIP on a long-lived working branch

[DrumRobot]

Problem

When committing accumulated, long-lived uncommitted changes on a shared/reused working branch, a file that was staged at some earlier point can become stale relative to the branch's current HEAD — other legitimate commits may have landed on the same file in the meantime. Blindly committing the staged diff for such a file risks silently dropping or reverting those intervening legitimate changes, because the staged snapshot no longer represents a clean diff against HEAD.

This was observed concretely: a single script file's staged content was found to differ from HEAD by roughly a dozen diff hunks, caused by other legitimate commits that had landed on the same file after the staged snapshot was taken. A working branch that accumulates dozens of staged and untracked files across many sessions is likely to contain more files in the same state, and "the pre-commit checks passed, so it's safe to commit as-is" is not a safe assumption for this class of file.

Scope

1. Before committing a staged file that has been sitting on a long-lived/reused working branch, check whether any commits have landed on that file since the staged snapshot was taken (e.g. compare git log history for the path against when the file was staged).
2. If intervening commits are found, the file must not be committed as-is — instead, reconstruct the intended change from current HEAD (e.g. by copying the file to a scratch location, diffing against the stale staged version, and reapplying only the deliberate delta) rather than trusting the stale staged diff.
3. Add this check as an explicit step to the relevant commit workflow (e.g. a commit-tidy / hunk-split procedure, or whichever workflow governs commits on this kind of long-lived working branch).
4. Given the potential scale (dozens of files across an accumulated backlog), a full one-time retroactive audit of everything currently staged is out of scope for this guard — the goal is to prevent the mistake going forward, not to audit the existing backlog in one pass.

Verification

Feature	Procedure	Expected Result
Stale staged file detected	Stage a file, then simulate an intervening commit touching the same file, then run the staleness check	Check reports the file as stale and blocks/warns before commit
Clean staged file passes	Stage a file with no intervening commits since staging	Check passes, file can be committed normally
Reconstruction procedure documented	Review the workflow step added by this change	Step describes the scratch-copy + reapply-intended-delta procedure, not just a generic warning