fix(repo-hygiene): git-tree-reset exit-7 failure path emits RestoredTracked: N without the RESTORED>0 warning message the success path prints

[kyle-sexton]

Observed during the #590 merge digest (control tower).

On the new exit-7 failure path (git clean failed, no unremovable-file warnings), the script emits RestoredTracked: N but skips the WARNING: restored N tracked file(s) message that the success path prints when RESTORED>0. The two paths should surface restore-guard activity identically — the warning is the human-visible signal that data-loss recovery fired.

Scope: plugins/repo-hygiene git-tree-reset.sh, failure-path output block added in #590.

Relates to #395 (family), #602 (sibling follow-up from same digest).

Filed by the control-tower session from a merge-digest finding.

[kyle-sexton]

This was generated by AI during triage.

Triage (T1 — routed ready)

Single-file, well-scoped bug: on the exit-7 failure path (git clean failed, no unremovable-file warnings), git-tree-reset.sh prints RestoredTracked: N but skips the WARNING: restored N tracked file(s) message that the success path emits when RESTORED>0. Fix: emit the same warning on the failure path when RESTORED>0, matching the success path's message exactly.

No design decision — mirror existing success-path output block. Related: #395 (family), #602 (sibling).

[kyle-sexton]

Folded into the rolling paper-cut sweep #657 per the v11 intake throttle (paper-cuts batch as sweep lines, consequence findings stay standalone). Content preserved as a checklist line there; this closure is the fold, not a wontfix. [Control tower, triage-audit execution 2026-07-20; operator veto window]