fix(protect-secrets): match Windows paths and register the search tool

[L4XB]

Fixes #55 — both halves of it.

Bug 1: backslash paths matched nothing

Every entry in SENSITIVE_FILES anchors its path boundary on /, and several use [^/] inside, so a tool-provided Windows path went past all of them:

$ node -e "process.stdout.write(JSON.stringify({tool_name:'Read',tool_input:{file_path:'C:\\\\Users\\\\me\\\\project\\\\.env'}}))" | node plugins/protect-secrets/protect-secrets.js
{}

That is not only .env: .envrc, SSH private keys and authorized_keys, AWS/kube/gcloud/azure/docker credentials, .netrc, .npmrc, .pypirc, .pgpass and the rest were all unprotected on Windows at every safety level, since the anchor is what failed rather than any single rule.

Matching now runs on a separator-normalized copy of the path:

function toPosixPath(filePath) {
  return typeof filePath === 'string' ? filePath.replace(/\\/g, '/') : filePath;
}

One helper instead of rewriting 25 anchors, so a pattern added later is covered by construction. The hook only ever reads the path, never opens it, so the rewrite stays local to matching; the allowlist is normalized the same way, which keeps C:\src\app\.env.example allowed.

Bug 2: the search tool never reached the hook

check() has handled Grep for a while and the test file covers it, but hooks/hooks.json registered Read|Edit|Write|Bash, so none of that ran for a real call: searching a .env for a key value was not inspected on any OS. The matcher now comes from the same list main() branches on:

const HANDLED_TOOLS = ['Read', 'Edit', 'Write', 'Bash', 'Grep'];

and a test reads hooks/hooks.json and asserts the two agree, in both directions — a tool handled in code but missing from the matcher is dead code, and a tool in the matcher that check() ignores costs a node start per call.

guard-pack had the same gap, so it gets the same wiring: Grep in its matcher and in PACK_TOOLS, and its protect-secrets entry now takes mod.HANDLED_TOOLS instead of keeping a second copy of that list. Its meta test derives the matcher from PACK_TOOLS rather than spelling it out. lib/protect-secrets.js is re-copied so the byte-identity pin holds.

Both plugin versions go to 1.0.1 so installed copies refresh.

Evidence

env -u CCH_SLA_WEBHOOK npm test
# 1624 tests, 1620 pass, 4 fail

The 4 failures are plugins/format-code cases that shell out to ruff, which is not installed in this environment; they fail identically on a clean checkout (1610 tests, 4 fail). Everything else is green, including the 14 tests added here.

Behaviour, before and after, through the real script:

payload	before	after
Read C:\Users\me\project\.env	{}	deny [env-file] Cannot read:
Grep {pattern:'API_KEY', path:'C:\app\.env'}	{}	deny [env-file] Cannot search:
Read C:\src\app\.env.example	{}	{}
Read C:\src\app\config.js	{}	{}

Negative controls, each reverted on its own:

• drop the normalization in checkFilePath → 9 of the new tests fail
• put Read\|Edit\|Write\|Bash back in hooks.json → the registration guard fails
• put the hardcoded tool list back in guard-pack's protect-secrets entry → the pack's search test fails

Also checked: garbage stdin still prints {} and exits 0, and all five touched JSON files parse.

One thing left out

BASH_PATTERNS has the same separator assumption in two places, cat-aws-creds and rm-aws-creds, which spell \.aws\/credentials. I left them alone rather than normalize a whole shell command, where backslashes are escapes and rewriting them would change meaning. Making just those two accept [\\/] is a small follow-up if you want it.

[L4XB]

Synced with main, which landed protect-secrets 1.1.0 (#58) and subagent-spawn-cap (#59) while this was open. The diff against main is unchanged in substance — same 13 files, same 150 insertions — but three things moved:

• PACK_TOOLS now reads Bash|Read|Edit|MultiEdit|Write|Agent|Task|Grep, picking up the two tools subagent-spawn-cap: per-session subagent spawn budget, wired into guard-pack #59 added to the pack.
• meta: the pack advertises exactly one PreToolUse registration had grown a hardcoded assert.strictEqual(..., "Bash|Read|Edit|MultiEdit|Write|Agent|Task"). I removed it rather than updating the string: the derived assert.deepStrictEqual(matcher.split("|"), PACK_TOOLS) this PR adds covers it and cannot drift, which is the whole point of protect-secrets: .env not blocked on Windows (Read/Edit/Write), and the search tool bypasses the guard entirely #55.
• Both plugin versions bumped 1.1.0 → 1.1.1.

node --test plugins/guard-pack/tests/guard-pack.test.js — 39 pass. node --test plugins/protect-secrets/tests/protect-secrets.test.js — 430 pass. The full npm test shows 1917 pass / 4 fail, and all four are format-code cells that shell out to ruff, which is not installed on this machine; they are untouched by this branch.