_matches_filter re-parses created_after per job inside session.list_jobs

[nficano]

src/arcp/_runtime/_handler_list_jobs.py:62 calls _matches_filter(job, body) once per job, and inside that helper src/arcp/_runtime/_handler_list_jobs.py:70 runs datetime.fromisoformat(body.filter.created_after.replace("Z", "+00:00")) on every invocation. The created_after string is shared across every job for a single session.list_jobs request, so the parse work and the replace allocation scale linearly with the number of jobs visited. The string is also already validated upstream, so the work is pure overhead. On Python 3.11+ the replace("Z", "+00:00") is redundant in any case — datetime.fromisoformat accepts "Z" natively — so removing it is a separate small win that also drops one string allocation per call. The same pattern repeats wherever the codebase parses ISO timestamps with the same replace: src/arcp/_messages/execution.py:78, src/arcp/_runtime/lease.py:70, and others.

Fix prompt: Hoist the parse out of the loop. Compute created_after_dt = datetime.fromisoformat(body.filter.created_after) once in handle_list_jobs at src/arcp/_runtime/_handler_list_jobs.py:27 (after body validation), pass the parsed datetime into _matches_filter, and drop the replace("Z", "+00:00") because the project targets Python 3.11+ where ISO Z is parsed natively. While at it, audit src/arcp/_messages/execution.py:78, src/arcp/_runtime/lease.py:70, and src/arcp/_client/dispatch.py:31 for the same redundant replace and remove the dead workarounds. Add a microbenchmark or simple count test that asserts datetime.fromisoformat is called O(1) times per list_jobs request regardless of job count.