docs(search): correct the RFC3339 timestamp claim, it works when quoted

The previous commit's warning said a timestamp carrying a time of day was
not understood at all, and told users to fall back to whole-day range
bounds. Both halves were wrong. Only the bare unquoted spelling fails:

    added:2005-01-01T00:00:00Z                            -> no match
    added:"2005-01-01T00:00:00Z"                          -> matches
    added:[2005-01-01T00:00:00Z to 2006-01-01T00:00:00Z]  -> matches

That is the ordinary quoting rule the surrounding docs already state, the
same one "-1 week" and "next monday" obey, so present the timestamp as a
working form rather than as a limitation and drop the false workaround:
range bounds carrying a time of day work fine.

A bound must be bare inside range brackets, where quoting it is rejected
outright, so document both halves of the rule rather than just "quote it".

Keep the zero-width warning distinct from the quoting rule now sitting above
it, since a reader who just learned quoting rescues "next monday" would
otherwise assume it rescues "-3 days". It does not: re-verified against
documents added at exactly those instants, the quoted offsets still match
only that one instant.

Pin the working spellings, which is the assertion that was missing: nothing
covered the quoted or range-bound forms, so a regression of a working
feature went undetected. Also pin that quoting does not rescue the
zero-width group.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/documents/tests/search/test_documented_syntax.py

@@ -271,6 +271,11 @@ class TestDocumentedDateForms:
             ("added:2005-03", "old"),
             ("added:[2005-01-01 to 2005-12-31]", "old"),
             ("added:[2005 to 2009]", "old"),
+            # A full timestamp works, but only quoted when it stands alone,
+            # and only unquoted when it is a range bound. The bare standalone
+            # spelling is pinned as a non-match below.
+            ('added:"2005-03-04T15:30:00Z"', "old"),
+            ("added:[2005-03-04T09:00:00Z to 2005-03-04T17:00:00Z]", "old"),
         ],
     )
     def test_documented_date_form_matches_its_day_or_month(
@@ -291,12 +296,19 @@ class TestDocumentedDateForms:
             "added:now",
             "added:noon",
             "added:midnight",
+            # Quoting is what rescues the other multi-word date expressions,
+            # so pin that it does not rescue these: the problem is the width
+            # of the resulting range, not the way the value is delimited.
+            'added:"now"',
+            'added:"midnight"',
             'added:"-3 days"',
             'added:"-1 week"',
             # The trap: this reports no diagnostics but parses as
             # And(added:now, "3", "days") - added:now plus stray text.
             "added:now - 3 days",
-            # A time-of-day component is split off and searched as text.
+            # The bare, unquoted spelling of a full timestamp. The quoted and
+            # range-bound spellings above do work and match this fixture's
+            # document; only this one silently degrades to a non-match.
             "added:2005-03-04T15:30:00Z",
         ],
     )