feat(tidy): non-destructive repo cleanup, plus 25 defect fixes including a shell injection

[leonardocandiani]

What this is

Two things: a new command that cleans up cluttered repos without ever deleting
anything, and 25 defects found by reading the plugin end to end, each one
reproduced by running the engine rather than by reading it.

The new command

/keepwright:tidy takes a repo that has filled up with backup files, committed
build output, byte-identical duplicates, modules nothing imports and an
unreadable root, and leaves it cleaner with every change reversible.

Nothing is ever deleted. The engine knows three operations and none destroys
bytes: quarantine moves a file into .attic/<date>/ keeping its original
path, untrack drops a path from the index while the file stays on disk, and
move relocates. There is no delete path in tidy-apply.ts, and CI greps the
source to keep it that way. It refuses a dirty tree and the default branch, so
deleting the branch is a complete escape hatch, and MANIFEST.json holds the
exact inverse of every operation.

What makes it more than a filename heuristic is the evidence. tidy-scan.ts
builds an import graph and walks it from the real entry points, then combines
that with git history and a mention sweep. A file is called an orphan only when
no entry point reaches it, nothing imports it, and no tracked file names it.
Everything else is a question, not an action. The scanner is deliberately
biased toward calling things used: a false "still in use" costs a line of
output, a false "unused" costs someone their code.

Verified: four refusal paths that write nothing, a dry run that leaves the
tree clean, and apply plus undo returning every blob hash to its prior state.
Against a clone of a real 555-file project, the project's own TypeScript
compiler reports the same zero errors before, after quarantining nine files,
and after the undo. An independent grep, written against a different
implementation than the graph, finds zero references to all nine.

The defects

Critical

The mention workflow interpolated the comment body into a run: script inside
single quotes. Actions substitutes into the script text before bash parses it,
so a comment with a quote broke out. The step fires on every
issue_comment.created, before the mention filter, which sits inside the same
already-substituted script. With contents: write and the schema's
self-hosted default, that was arbitrary execution on the maintainer's machine
by anyone who can comment on an issue. Fixed here, along with three more of the
same class, and CI now fails on any free-text GitHub context inside a run:.

Broke the product in ordinary use

• Every commit failed right after setup: the hook called a script no template
  generated, and carried placeholders as literal text that it tried to execute.
• A repo that already had a CLAUDE.md got a red pipeline on its first push,
  which is exactly the "works on any existing repo" case the README advertises.
• The review skill globbed rules 01 through 07, so two of the nine were never
  read.

Silent failures, the worst category

• With no criticalFiles set, the workflow grepped for the literal string
  {{CRITICAL_FILE_1}}: the warning never fired and the repo looked watched.
• The audit counted a repo's own ci.yml as keepwright coverage.
• The banned-terms grep matched an authorship trailer anywhere in a line, and
  REVIEW.md documents that string, so the repo blocked any PR editing its own
  review doc.
• The documented merge bypass expanded to a literal word instead of reading its
  variable whenever the project name had a hyphen.
• Derived patterns, the product's central claim, were mined and declared and
  then reached nothing.

Every lesson became a check with an exit code

apply.ts refuses to install when a placeholder would survive into an executed
file, and that gate found the CRITICAL_FILE defect on its first run. The five
diverging secret pattern lists became one data file that both the shell greps
and the TypeScript scanners read, with the more permissive bound winning
wherever copies disagreed. CI installs the plugin into scratch greenfield and
brownfield repos, plants a fake credential and fails if the validator passes
it, and fails if an emptied pattern list is accepted rather than refused.

Every gate has a positive control: the defect was reintroduced and the gate was
confirmed to reject it.

Removed

The orchestration workflows are no longer copied into the target repo, where
nothing invoked them and where they could not run standalone. customValidators
and mode leave the schema: a versioned config should describe the repo, not
the action being performed on it.

What still needs to be proven

The new CI jobs were simulated locally step by step, with positive controls,
but have never run on GitHub Actions. This PR is that test.

EMPIRICAL VALIDATION

Local suite, 11 checks, all green:

PASS: 11 workflow files parse
PASS: gate accepts the fix, rejects the reintroduced injection, no false positive
PASS: greenfield runnable, brownfield green on day one, apply idempotent
PASS: refusals write nothing, dry run is the default, undo restores byte for byte
PASS: .gitignore returns to its exact prior content
PASS: unknown flag exits 2 on both
PASS: no filesystem delete anywhere in the apply engine
PASS: every git rm is --cached (index only)
PASS: 4 findings, 0 of them proposing to move a live file
PASS: REVIEW.md gets the repo's own patterns, and says so plainly when there are none
PASS: 11 credential shapes caught from shell and from JS, no false positive, empty list fails loudly

Compiler proof on a real repo:

BASELINE typecheck: errors before: 0
applied: quarantine 9
AFTER typecheck: errors after: 0
UNDO: reversed 9 -> errors after undo: 0