perf(aggs): bound the zone-offset probe to a six-byte window at the end - #119

The guard added for issue #96 was correct but paid for itself with a worse
regression: it hunted for the offset's sign by scanning `[11, len - 5)`, which
is O(len). Any value whose window holds no `+`, `,`, `-` or non-ASCII byte —
prose, digits, anything long — ran that scan to the end, where before the
guard `parse_date_ms` failed in O(1)-ish time. Measured, per-pass paired
timings pinned to one core, ns/op before the guard -> with it: 512 B 214 ->
326, 4 KB prose 214 -> 1139, 4 KB digits 254 -> 1214, 64 KB 804 -> 15587.
That is a 19x regression on the same per-document path the guard exists to
make cheaper.

A `%z` offset cannot be anywhere but the end: it closes the pattern and
`parse_from_str` insists the whole value be consumed, so an accepted value
ends with the offset's two minute digits and the sign sits a fixed distance
in front of them — `len - 5` for `±HHMM`, `len - 6` for `±HH:MM` and
`±HH MM`. So the probe now reads a six-byte tail (sign + `HH` + one separator
+ `MM`, named and derived from those spellings) and nothing else. No scan, no
loop, no dependence on length.

chrono's separator scanner does accept a longer run — `+00 : 00` really does
parse — which walks the sign out of any constant window. Chasing that run
would put the O(len) back, so it is over-matched from the separators it
leaves behind instead: the probe stays one-sided, and an over-match only
pays for the parse that would have run anyway.

Now best-or-tied on every class, against both origin/main and the scanning
guard (ns/op, 12 pinned runs x 41 interleaved passes, median of per-pass
ratios; 1.00x here is the noise floor, established by the two classes that
return before the probe is even reached):

  class                  main       prev        now   vs main    vs prev
  offsetless ISO        211.8      107.2      108.2    0.513x     1.001x
  +HH:MM                 19.8       19.8       19.8    1.000x     1.000x
  +HHMM                 136.8      136.1      135.9    0.997x     0.999x
  Z-suffixed             18.0       17.9       17.9    1.000x     1.001x
  epoch integer         241.8      219.6      219.8    0.910x     0.998x
  128 B sign-free       215.3      218.2      197.0    0.905x     0.897x
  512 B sign-free       213.5      325.9      195.1    0.906x     0.593x
  4 KB prose            213.9     1139.1      197.4    0.920x     0.169x
  4 KB digits           254.1     1213.7      232.1    0.912x     0.192x
  64 KB sign-free       804.3    15587.1      774.2    0.974x     0.048x

Output is unchanged: 16315 values — every zone spelling including `+0000`,
`+00:00`, `+00 00`, `+00:::00`, `Z`, `z` and U+2212, offsetless ISO, epoch
integers, fractional seconds of every width, garbage and multi-kilobyte
blobs — parse byte-identically under origin/main, the scanning guard and
this probe.

`zone_offset_probe_window_is_bounded` pins the property the scan lost: the
probe's answer is fixed by the last six bytes plus the length, so filler in
front of them cannot change it or add work — including filler made entirely
of the bytes the old scan was hunting for, at 64 B through 64 KB.

…scan

`zone_offset_probe_window_is_bounded` is true but does not discriminate: it
grows a HOMOGENEOUS filler and asserts the answer does not change, and an
O(len) scan's answer is invariant under exactly that transformation — a `"+"`
filler contains a `+` at every length and an `"a"` filler contains none at any
length. Verified by mutation: replacing the probe's body with the previous
unbounded scan leaves that test green, so nothing in the suite would have
caught the regression coming back.

The property that characterises the fix is that the answer depends on
`(len, last ZONE_OFFSET_PROBE_BYTES bytes)` and nothing else. The new test
holds BOTH the length and the window fixed and perturbs every byte strictly
below the window, over 8 tail shapes x 5 lengths x 9 single-byte edits.

Mutation-checked both ways on this tree:
  bounded probe (as shipped)  -> passes, 3 168 checks
  unbounded scan restored     -> FAILS at "editing byte 14 of 22 ... to 0x3a",
                                 while the old scaling test still passes