test: the filter's created-at endpoint can be wrong by 100x and its parity suite still passes #981

A mutation of the filter's created_at window by 100× leaves filter_schema_parity at 54/54 green. The suite agrees with itself, not with the capture.

The measurement

In a git archive copy of the branch, validate_timestamp's bound was moved from CREATED_AT_LIMIT as f64 (10¹⁰) to 10⁸.

cargo test -p nostream-core --test filter_schema_parity    # 54 passed; 0 failed

The nearest invalid row in that file is 1_672_295_751_103 (crates/nostream-core/tests/filter_schema_parity.rs:211) — 167× the real limit. Every other created_at/since/until row sits far below 10⁸ as well, so nothing in the table lies between a wrong bound and a right one.

The port's event-side test does catch a constant change (wire_codec), so the gap is specific to the filter surface.

Why it matters

A parity suite that cannot fail is the thing this rewrite exists to prevent: it reports agreement while measuring nothing about the boundary it names. The created_at bound is one line, so the risk of a wrong value is low — but the precedent is not: any other endpoint in that table could be wrong by two orders of magnitude and pass.

What a fix needs

Rows at the boundary itself, on the filter surface:

• since/until at 10_000_000_000 - 1 → accepted;
• since/until at 10_000_000_000 → refused with the capture's message;
• the same pair for until, and for a limit-style numeric field if one shares the code path.

The capture's own answer at those two points should be measured with messageSchema rather than assumed, since the port and the capture have already disagreed once on a boundary in this area.

Found while closing #960/#961 (PR #980): the substitution there is provably exact (10^10 < 2^53, so the as f64 cast cannot round), which is why it was accepted — but the test that would have caught a wrong value does not exist.