0.5.1 - Match debugging metadata

This release makes blocked and tracked matches explainable: the match metadata now names the target a rule fired on and shows the value that triggered it. No breaking changes.

Match debugging metadata

Blocked requests carry two new MatchResult metadata keys alongside msg and owasp_log_data:

• owasp_matched_variable - the target the first matching rule fired on, e.g. REQUEST_HEADERS:User-Agent or REQUEST_COOKIES:cart. The member name keeps the casing the client sent, so the log points at the real request data. On a fail-closed block it names the variable that failed closed.
• owasp_matched_value - the value the rule fired on, kept readable so the match can be understood and tuned: sanitized (control characters stripped) and length-bounded (200 bytes). Credential targets - cookie values and Authorization-type headers (Authorization, Cookie, Proxy-Authorization, X-Api-Key, X-Auth-Token) - appear as [redacted]; the target name stays visible for tuning.

The PSR-3 per-match log context gains the same matched_value, redacted by the same single choke point, so both sinks stay consistent.

This turns an opaque block such as X-Phirewall-Owasp-Rule: 942340 into an actionable one: the metadata now shows owasp_matched_variable: REQUEST_COOKIES:cart, identifying the classic cookie false positive that can then be tuned away with excludeTarget('REQUEST_COOKIES:cart') instead of disabling the rule.

RuleMatch gained a public matchedValue property, appended after failClosed so positional construction against 0.5.0 keeps working.

Full Changelog: 0.5.0...0.5.1