URL-encode Nightscout date filters instead of retrying with a mangled timestamp

[xannasavin]

arrow's isoformat() ends a timestamp with its UTC offset, e.g. 2026-07-16T00:00:00+02:00. Placed raw into a query string, + is a reserved character that servers decode as a space, so Nightscout receives 2026-07-16T00:00:00 02:00 and answers "could not parse as a valid ISO-8601 date". Every user on a positive UTC offset hits this on every date-filtered query.

The current workaround

time_range() takes a t_to_space flag, and each last_uploaded_* method wraps its request so that a failure retries with T replaced by a space, treating a second failure as "no previous entry".

That gets a response, but it works around the symptom rather than the cause: the value is still mangled, every affected query costs two round-trips, and a genuinely empty result becomes indistinguishable from a rejected one.

This change

Percent-encodes the value instead. The offset survives, the first request succeeds, and the t_to_space fallback and its retry wrapper become dead code, so they are removed:

def fmt(date: DateLike) -> str:
    ret = format_datetime(date)
    return urllib.parse.quote(ret, safe='')

Tests

There was no coverage of time_range() before. This adds tests that a positive offset is encoded rather than emitted raw, that the encoded value round-trips back to the original instant, that negative offsets and Z suffixes still parse, and the both-bounds / no-bounds cases.

The encoding test fails on current master:

AssertionError: '+' unexpectedly found in '&find[created_at][$gte]=2026-07-16T00:00:00+02:00'

and passes with this change.

I have been running this in my EU deployment since May. Split out of #143, which bundled too many unrelated changes to be reviewable.

[jwoglom]

Thanks - will merge!