Describe what --harden-files actually verifies

[erikdarlingdata]

The [Unreleased] #2352 entry promised "VERIFIES each one afterwards" but described only the readability half, and said nothing about which account it hardens FOR — which is exactly the part that turned out to matter (#2371, fixed in #2372).

Docs only; no code. Fold-into-3.5.0 is still pending the soak.

[claude]

Reviewed. This is a docs-only CHANGELOG.md edit (1 line changed, no code) — verified the added text against the actual implementation rather than just proofreading:

• "Hardens for the account the SERVICE is registered under (the SCM's ObjectName...)" — matches DarlingFileSecurity.RegisteredServiceAccount reading ObjectName from the service's registry key, and DarlingCliCommands' --harden-files handler calling HardenForAccount(registered) before falling back to the caller's own identity when the service isn't registered.
• "gMSA is handled" — confirmed by the RegisteredServiceAccount doc comment and NTAccount(...).Translate(...) path, which resolves domain accounts and gMSAs the same way.
• "Verification covers both directions... a locked-out target fails rather than reporting SECURED" — matches the IsReadableByOrdinaryUsers (too-open) + GrantsHardenedAccount (too-closed → LOCKED OUT) pair in the harden loop; a target that passes only the first check but fails the second is correctly reported as exposed, not SECURED.

No T-SQL, no Lite/Darling parity surface (this string only exists in CHANGELOG.md), nothing security- or perf-relevant to flag. No issues found — the new wording is accurate and reads well against the code it describes.