Add supply_chain_install_remote_source rule (protect npm/pnpm install shorthands)

[sarahxsanders]

Problem and acceptable goal

Problem this change addresses

To let smaller/faster models (e.g. gpt-5-mini) run without unnecessary permission prompts, the agent allowlist is being widened to permit shorthand install commands like npm i and pnpm i. Once a bare npm i <arg> no longer prompts, the newly-reachable risk is an agent being steered into npm i <remote-source> — installing straight from a remote tarball URL or a git repo, which bypasses the registry's published-version review and runs the fetched package's lifecycle scripts from arbitrary state. This is a classic supply-chain vector and nothing in the Warlock caught it. This PR adds a narrow rule for that shape while deliberately leaving benign npm i <pkg-name> unflagged.

Why the Warlock is the right home for this change:

Detecting a dangerous content shape in a shell command is exactly the Warlock's job. The allowlist widening lives in the consumer (harness), but the pattern-detection that protects the shapes around it belongs with the other supply_chain install rules (supply_chain_npm_install_global, supply_chain_wrong_posthog_package), not duplicated in each consumer.

Changes

• New rule supply_chain_install_remote_source (severity high, category supply_chain, action block, scan_context = command) matching JS package-manager installs (npm/pnpm/yarn/bun/cnpm) from a remote .tgz/.tar.gz tarball URL or a git source (git+https, git+ssh, git://, git@host:, github:/gitlab:/bitbucket:).
• Deliberately narrow: does not flag a normal registry install by name, a --registry flag pointing at a registry root, a local-path install, or deno (URL installs are idiomatic there).
• Positive + negative vitest tests, including the benign npm i <pkg> / pnpm i <pkg> shorthands the allowlist change enables.

Anti-goal check

• This is not a code-quality or best-practice check (those belong in wizard or a linter)
• This does not add policy or enforcement logic (the Warlock detects, consumers decide)
• This does not add phase, tool, or workflow awareness to the engine (the Warlock is engine-only)
• This does not encode wizard-specific assumptions (the Warlock serves multiple consumers)

Test plan

• Existing tests pass (pnpm test) — 532 passed
• Build succeeds (pnpm build)
• For new rules: added a positive-match test (content that should match)
• For new rules: added a negative-match test (similar content that should not match – guards against false positives)
• For new rules: includes scan_context metadata (command)
• For API changes: n/a — no public API change

---

Created with PostHog from a Slack thread