security: remove runtime require of unverified modifiers-napi package

[salmanrajz]

Fixes #7

Problem

src/utils/modifiers.ts has live require('modifiers-napi') calls that execute at runtime. The modifiers-napi package is an Anthropic-internal native addon, but a package with the same name exists on npm — this is a supply chain attack vector.

While the build script (scripts/build.ts) stubs these native modules during bundling, the source code still has direct require() calls that would execute when running without the bundler (e.g. bun run dev, ts-node, or any unbundled execution path).

I verified all 5 native addon package names exist on npm:

• modifiers-napi ✅ exists
• audio-capture-napi ✅ exists
• image-processor-napi ✅ exists
• url-handler-napi ✅ exists
• color-diff-napi ✅ exists

Fix

Replaced both functions in modifiers.ts (prewarmModifiers and isModifierPressed) with safe no-ops. Modifier key detection is macOS-only and not needed in the open-source build.

The other native addon imports (image-processor-napi, audio-capture-napi, url-handler-napi) use dynamic await import() behind feature flags that are all disabled, so they are lower risk but could be addressed similarly in a follow-up.

Verification

Build passes: bun run build produces dist/cli.mjs successfully.

[salmanrajz]

Good questions!

macOS impact: The modifier detection was used for checking if Shift/Command/etc keys were held during certain interactions. Since the open-source build already had all feature flags disabled (VOICE_MODE, PROACTIVE, etc.) and the build script was stubbing modifiers-napi to a no-op anyway, the runtime behavior is identical — the bundled dist/cli.mjs was never actually calling the real native module. The only difference is that unbundled execution paths (bun run dev, ts-node) are now safe too.

Windows/WSL: This change doesn't affect the Windows situation. The original code already had a process.platform !== 'darwin' guard that returned early on non-macOS, so Windows was already getting no-op behavior. The WSL requirement likely comes from other parts of the codebase (shell commands, Unix-specific paths, etc.) rather than this module.