fix(scripts): stop pruning run-log entries with non-ISO run_id

[KhaiTrang1995]

Problem

scripts/append-run-log.mjs prunes entries older than 30 days using
new Date(obj.run_id).getTime(). JS's Date constructor is lenient: a
non-ISO run_id (a numeric GitHub run id, a custom slug like "run-1")
doesn't reliably parse to NaN -- it can parse into a spurious
in-range-looking date instead ("run-1" -> 2001-01-01), which then
reads as 30+ days old and gets silently deleted on the very next
append, even though the entry was just written. tools/loop-metrics
already handles this exact run_id shape correctly (keep on
unparseable rather than drop); this script did the opposite.

Fix

Only strings shaped like an ISO date (^\d{4}-\d{2}-\d{2}) are parsed
as timestamps for pruning at all; anything else is always kept,
matching loop-metrics' handling.

Also fixes append-run-log.test.mjs's own SCRIPT path, which used
new URL(...).pathname -- on Windows that yields a leading-slash path
("/D:/...") that node's CLI mis-resolves relative to the current
drive instead of as absolute (the same class of bug already fixed for
tools/loop/test/files.test.mjs in #502). Switched to fileURLToPath().

Test plan

Added a regression test appending an entry with a non-ISO run_id
("run-1") followed by a second append, asserting the first entry
survives. node --test scripts/append-run-log.test.mjs: 3/3 passing
(this also required the Windows path fix to even run locally).

[cobusgreyling]

Correct fix. JS Date is too lenient on slugs like run-1; gating prune on ISO-shaped run_id matches loop-metrics and the regression test locks it. fileURLToPath() for the test script path is the right Windows fix.