fix quadratic backtracking in timestamp parse regex

[arib06]

Pull Request Checklist

• 🧪 Added tests for changed code.
• 🛠️ All tests pass when run locally (run tox or make test to find out!).
• 🧹 All linting checks pass when run locally (run tox -e lint or make lint to find out!).
• 📚 Updated documentation for changed code.
• ⏩ Code is up-to-date with the master branch.

Description of Changes

The X timestamp token uses _TIMESTAMP_RE = ^\-?\d+\.?\d+$, whose two adjacent unbounded \d+ groups make the engine try every split of a digit run when the string ends in a non-digit, so parse(value, "X") on attacker-controlled input degrades to O(n^2). A ~32 KB string of digits plus one trailing character takes about 2.8s on my machine (8 KB ~0.35s, 16 KB ~1.4s), while a real timestamp parses in microseconds. The rewrite ^\-?(?:\d+\.\d+|\d{2,})$ accepts exactly the same strings (verified by exhaustive comparison over every string up to length 5 from {0,9,-,.}, zero differences, including the existing rejections of 1565982019. and .1565982019) and matches in linear time, so the same 32 KB input now finishes in well under a millisecond.