fix: report Notification BootId as stored; remove unsourced doc claims

[abrignoni]

Fixes from a documentation audit of artifacts touched 2026-07-29/30, applying the standard that notes and descriptions must not state what data means unless the data (or a cited source) proves it.

Behavior change

windowsSystem / Notifications: Notification.BootId was converted as a Windows FILETIME and reported as "Boot ID Time (UTC)". Nothing in the repo establishes the field is a timestamp — the lab validation never covered BootId, the unit test only proved the conversion of a synthetic FILETIME it inserted itself, and public wpndatabase research describes BootId as a boot sequence identifier. A real counter value would have rendered as a bogus 1601-era timestamp in front of an examiner. The column is now "Boot ID (database value)", reported as stored, with a test asserting the raw pass-through.

Documentation-only fixes

• Notifications note: the FILETIME/UTC claim now covers only arrival and expiry (lab validated); Boot ID is stated as reported-as-stored.
• SetupAPI note: "device-local because the log records no UTC offset" was a fact stated with a justification that doesn't support it (a missing offset shows ambiguity, not local time); now attributed to Microsoft's documented SetupAPI logging behavior.
• Photos note: "Alternate Date Taken is an app-maintained fallback" was an unsourced purpose attribution; now described as a separate app-recorded date whose derivation is not documented.
• Alarms: "Days of Week (bitmask)" asserted an encoding never established; now "(database value)", and the notes state that Recurring is derived from a nonzero Days of Week only when the source carries no IsRecurring value.

All 10 Windows artifact tests pass; lint gate clean.

🤖 Generated with Claude Code