check-intentlisted

# check-intent Use this right after implementation, before `code-review`. `code-review` judges whether the diff is good; this checks whether the diff is the one that was actually asked for. A plan drifts during a long implementation session more often than it is deliberately changed. ## When to use it - Right after implementation is done, before `code-review` or `prepare-pr`. - When a written plan, an issue, or an explicit ask exists to check the diff against. - Skip it when there was no separate plan step: the ask and the diff are the same small fix. ## Required inputs - The stated plan, issue, or ask: what was supposed to change, and why. - The diff or the branch, in full: every file it touches. ## Steps 1. List every distinct item the plan or ask called for, one line each, at the grain the plan itself used: a step in a written plan, a bullet in an ask, or (with no separate plan) the change's own stated outcome. Do not fold "and tests for it" or a downstream fixup a change of this kind always needs into one line with the change itself; a grain too coarse to check against the diff reads as Done while the real work underneath it goes unverified. 2. Walk the diff file by file. For each plan item, mark it Done, Missing, or Changed-approach (the diff solves it a different way than the plan named). For each file the diff touches that traces to no plan item, mark it Extra. A file that implements a Changed-approach item is accounted for by that item; it