Fix automatic countdown being skewed by the UTC offset

[danielchalmers]

The default countdown display (empty format, the "Automatic" preset) was wrong by the machine's UTC offset for every non-UTC user. On UTC-6, a target of exactly now showed "6 hours from now".

Cause: nowDateTime is a local wall-clock value with Kind=Unspecified. Humanizer converts the comparison date into the frame implied by utcDate (ToLocalTime() for false), and that conversion shifts Unspecified values by the UTC offset.

Fix: pin the comparison date's Kind to Local so the conversion is a no-op. Verified empirically against the built exe on a UTC-6 machine:

Target	Before	After
exactly now	6 hours from now	now
+3 hours	9 hours from now	3 hours from now
-3 hours	3 hours from now	3 hours ago
-25 hours	19 hours ago	yesterday

• Tokenized countdown formats were never affected (they subtract the dates directly)
• Not a v5.5.0 regression; the call is identical at v5.4.0
• New tests assert the humanized wording relative to now; note CI runners are UTC where the old code also passed, so the proof is the local run above