fix(wineventlog): map final WFP and login outcomes

[kryonsx]

Windows Filtering Platform (WFP) events were losing the final connection decision and both endpoint IPs in the normalized log. The filter also treated an explicit-credential attempt (4648) and an account lockout (4740) as successful operations. Either problem can distort threat-intelligence correlation: a blocked flow may look undecided, while an unrelated attempt can look like a completed login.

This change maps 5156 to success only when WFP reports an allowed connection; 5150–5153, 5155, 5157 and 5159 map to denied for their documented blocked packet/connection/listen/bind operation. Permitted listen and bind events (5154/5158) do not establish a connection and remain unset. 4648 and 4740 no longer map to success. A prior incoming actionResult is cleared before the final decision is derived. For 5152/5156/5157, validated IP endpoints are promoted with direction-aware attribution, while invalid or unspecified addresses remain vendor detail under log..

Microsoft event contracts: explicit credential attempt 4648, account lockout 4740, blocked packet 5150, more restrictive packet block 5151, blocked packet 5152, more restrictive packet block 5153, permitted listen 5154, blocked listen 5155, allowed connection 5156, blocked connection 5157, permitted bind 5158, blocked bind 5159, and the standard event schema. Reviewed UTMStack snapshot: ab96ae9a685c54c974253ec517c688a7557019e9; rule SDK v1.1.33; schema wiki revision c18b54bd5ea5a34abb0e690458d73f89835edd29.

Validation: 24 fabricated raw Windows events cover inbound/outbound IPv4, IPv6, blocked and allowed WFP outcomes, malformed/unspecified addresses, non-connection listen/bind events, final logon success/failure, credential validation, and a positive/negative shipped-rule control. The pinned-SDK ordered-filter regression and full plugins/alerts module pass. The isolated actual parser produced 24/24 expected complete events and one expected shipped-rule control alert; the original filter passed 9/24 assertions on the same cases. That parser build has plugin/SDK dependencies different from the reviewed snapshot; its event writer has a separate NDJSON framing issue, so assertions decode its complete object stream.

Read-only bounded production records included allowed and blocked WFP events whose raw endpoints and decisions were absent from stored normalized fields. Their identifiers and source details remain in private evidence. No deployment, production alert creation, threat-intelligence membership, or notification was tested. No shipped Windows rule predicate reads actionResult. The shared TI outcome consumer has a separately tested draft requiring exact confirmed success and should be reviewed before relying on these canonical outcomes for TI alerts.