fix(sensor): correct Microsoft-Windows-Kernel-File provider GUID

[ymat19]

Summary

1. Correct the provider GUID

• KERNEL_FILE_GUID used an incorrect final node (edd08927-9cc4-4e65-b970-63462d3f77bd), which is not a registered ETW provider. Enabling an unregistered provider GUID silently succeeds but delivers no events, so no file telemetry was ever produced on Windows and file_event Sigma rules could never fire.
• Correct it to the real Microsoft-Windows-Kernel-File GUID edd08927-9cc4-4e65-b970-c2560fb5c289, confirmed via logman query providers "Microsoft-Windows-Kernel-File".

2. Decode manifest events correctly (fixes #133)

As confirmed in the live capture in #133, this manifest provider emits file events with opcode 0, so the previous MOF FileIo opcode routing (64/65/70/71/72) classified every event as Modify → Sysmon event ID 11, and Delete/Rename lost their path:

• Route file events by manifest event IDs: Create (12) → create, DeletePath (26) → delete, RenamePath (27) → rename; everything else under the enabled keywords, including Write (16), stays modify.
• Read FilePath for DeletePath/RenamePath/SetLinkPath events (they carry no FileName); other events keep reading FileName.
• Derive the file action code in mapper.rs from the routed action so events map onto the shared 64/65/70/71 action-code scheme already used by the Linux and macOS sensors (create/write → Sysmon 11, delete → 23, rename → 71).
• Rename the keyword constants to match the manifest (WRITE 0x200, DELETE_PATH 0x400, RENAME_SETLINK_PATH 0x800). The enabled mask is unchanged (0xE90).

Fixes #133

Verification

• Before: capturing with the old GUID (via the agent or logman) yields 0 file events for create/write/rename/delete operations (only the trace-session header event).
• After the GUID fix: the same keyword/level captures file events, cross-checked against logman + tracerpt (thousands of file events captured).
• Unit tests added covering event IDs 12, 16, 26, 27, the FilePath/FileName selection, and the action-code/Sysmon-ID mapping.
• cargo fmt --check, cargo check --locked --target x86_64-pc-windows-gnu, and cargo clippy --locked --all-targets --target x86_64-pc-windows-gnu -- -D clippy::all pass.

End-to-end verification of the decoder fix (Windows 11)

Verified this branch (cbab4ee) live on a Windows 11 (26100) machine:

• cargo test --locked passes (174 tests, 0 failures), including the new Kernel-File routing/mapping tests.
• Ran the agent (rustinel run, admin) with per-category Sigma test rules (file_create / file_change / file_rename / file_delete) matching a test path, then performed create → write → rename → delete on a test file:

Operation	Fired rule category	event.action	event.code	Path
Create	file_create	file-create	11	full path from FileName
Write	file_create¹	file-change	11	full path
Rename	file_rename	file-rename	71	new path from FilePath
Delete	file_delete	file-delete	23	path from FilePath

¹ Writes normalize to event ID 11 and therefore alias to the file_event/file_create Sigma categories — same as the Linux and macOS sensors; the ECS event.action still distinguishes create vs change via the action code.

Before this fix, all of these surfaced as file-change / event ID 11, and rename/delete carried no path.

[Karib0u]

I verified the provider on a Windows 11 lab VM with a live ETW capture.

The GUID change in this PR is correct: Microsoft-Windows-Kernel-File resolves to edd08927-9cc4-4e65-b970-c2560fb5c289, and the old GUID is not registered.

The capture also exposed a separate decoder issue:

Operation	Event ID	Opcode	Path field
Create	12	0	FileName
Write	16	0	none
Rename	27	0	FilePath
Delete	26	0	FilePath

The current code routes file events using opcode values 64, 65, 70, 71, and 72. With this provider, the opcode is 0, so these events fall through as Modify and normalize to event ID 11. Rename and delete also lose their path because the decoder only reads FileName.

I opened #133 with the full evidence and suggested acceptance criteria:
#133

Please consider expanding this PR or following it with the event-ID and field-mapping fixes.

[ymat19]

@Karib0u Thanks for the live verification and the detailed capture in #133 — that made the decoder fix straightforward. I've expanded this PR to cover it:

• File events are now routed by manifest event IDs (Create 12, DeletePath 26, RenamePath 27; Write 16 and the rest stay modify) instead of MOF FileIo opcodes.
• FilePath is read for DeletePath/RenamePath/SetLinkPath, so delete and rename no longer lose their target path.
• The file action code in mapper.rs is derived from the routed action, which puts these events on the same 64/65/70/71 scheme the Linux/macOS sensors use (create/write → Sysmon 11, delete → 23, rename → 71).
• Keyword constants renamed to match the manifest (mask unchanged at 0xE90), and unit tests added for event IDs 12/16/26/27 and the path-field selection.

I also re-verified end to end on a Windows 11 machine: with per-category Sigma test rules, create fires as file-create/11, write as file-change/11, rename as file-rename/71 with the new path, and delete as file-delete/23 — details in the updated PR description.