fix(config): pass excluded_semantic_detection_headers and detection_max_scan_seconds through from_security_config

[rennf93]

Closes #82

from_security_config now passes the two detection fields it dropped into the engine's DetectionExclusionConfig:

• excluded_semantic_detection_headers, available on the engine since guard-core-rs #137. Listing it alone now installs the exclusion block, which previously only the four exclusion lists and the category set did.
• detection_max_scan_seconds, mapped to DetectionExclusionConfig::max_scan_seconds. A value other than the engine default of 10.0 installs the block on its own. A config with the default value and an explicitly empty category set still installs nothing, as before.

With these two, every detection field of SecurityConfig reaches the engine.

Tests

Three tests per adapter failed before the change and pass now: the semantic header set reaches the installed engine config, a custom cap alone installs the block with that value, and a spent budget (cap 0.0) makes the engine answer a threat for a benign request (HTTP 400), while the default config forwards it.

I ran everything ci.yml runs: check, fmt, clippy with -D warnings, the pattern-probe build, cargo test, cargo doc, the 100% line coverage gate, and the MSRV 1.92 check and test, all against my checkout of the engine branch.

Merge order

This needs Guard-Core/guard-core-rs #139 merged first: the max_scan_seconds field and scan_budget module exist only there, and this repo's CI checks out the engine's master as its sibling. I did not touch Cargo.lock.