fix(scanner): stop scanning the current directory when YARA is disabled

[ymat19]

Summary

When scanner.yara_enabled = false (or when loading the configured rules fails), all three platform runtimes built the fallback "empty" scanner with Scanner::new(Path::new(".")). Since Scanner::new recursively walks the given directory looking for .yar/.yara files, the agent ended up scanning whatever its current working directory happened to be at startup — with YARA explicitly disabled.

• Add Scanner::empty(), which builds a zero-rule scanner without any filesystem access.
• Use it in the disabled / load-failure fallbacks in runtime/windows.rs, runtime/linux.rs, and runtime/macos.rs (the now-unneeded Path imports are removed).
• The normal rule-loading path (Scanner::new) is untouched.

Fixes #134

Verification

• Unit test added: Scanner::empty() reports zero found/compiled/failed rule files. Full cargo test --locked passes on Linux and Windows.
• cargo fmt --check and cargo clippy --locked --all-targets -- -D clippy::all pass on Linux and Windows targets.

End-to-end (Windows 11, YARA disabled, cwd = a large user-profile directory)

	Startup (launch → ETW trace session started)	Loading YARA rules from: "." in log	spurious YARA compile warnings
before (b4e0293)	>300 s (timed out, sensors never started)	yes	7
after (this branch)	1.5 s	no	0

No-regression checks (Windows 11, on this branch)

• YARA disabled: the detection pipeline still works end to end — file create/write/rename/delete operations fire the corresponding Sigma rules, even when the agent is launched from the same large working directory that previously blocked startup.
• YARA enabled: the configured rules directory loads normally (Found 1 rule files, compiled 1 successfully) and a YARA alert fires as expected on a process scan. No working-directory walk happens in either mode.

Same behavior confirmed on Linux with a synthetic 40k-entry tree as the working directory: the walk and the misleading compile warnings occur only before the fix, and the YARA-enabled load path is unchanged.

Not verified on macOS: the macOS runtime change is the same mechanical substitution as the other two platforms, but I could not runtime-test it — coverage there is compile/test via CI (clippy-macos, test-macos) only.