fix: suppress false positives in sec-hardcoded-url and crypto/hardcoded-secret

[ajianaz]

Summary

Fixes false positives in the security scanner and rule engine that were flagging legitimate code patterns as security issues.

Closes #357. Closes #364.

Changes

builtin.rs — Extended post_match_filter

Added is_false_positive_url() and is_false_positive_secret() helper functions with exclusions for:

• SVG xmlns / xlink:href — Namespace URIs, not network connections
• Docker internal hostnames (http://redis:6379) — No dots = internal, no TLS needed
• Loopback addresses (localhost, 127.0.0.1, 0.0.0.0) — Already safe
• Comments and docstrings (//, #, <!--, ///, triple quotes) — Not executable code
• Empty string values (= '', = "", = $state('')) — No actual secret
• Svelte $state() / bind: — UI framework bindings, not credentials
• Bare variable references — e.g. { app_secret: formAppSecret } — RHS is a variable

security_scanner.rs — Wired post_match_filter into scan loop

Both the builtin rule engine and the security scanner now share the same false-positive suppression logic via post_match_filter().

Tests

• 14 new unit tests in builtin::tests covering all filter branches
• 3 new integration tests in security_scanner::tests for end-to-end verification
• 731 total tests pass, 0 failures

No breaking changes

All existing detections remain intact. The filter only suppresses matches that were previously false positives — it never adds new findings.