fix(ci): give the Windows process probe a real deadline, and close the trace-recorder leak (#3661)

Two flakes, both with a diagnosable cause, that were the only checks still red on
main after #3635 and #3638 cleared the previous pair.

test-embed-windows: test_reads_the_command_line_of_a_live_process failed on
three of seven runs across different branches within an hour, so it is not a
broken runner image. The timings name it — the two neighbouring tests that
*expect* None (they look up a pid that cannot exist) take 5.05s and 5.02s,
sitting exactly on _run_probe's 5s timeout. On Windows the command line comes
from WMI: wmic first, which is absent from current Windows images and fails
instantly, then a fresh PowerShell running Get-CimInstance — whose cold start
alone can pass five seconds on a loaded machine, before WMI is asked anything.

That is not only a test problem. _process_matches reads None as "not one of our
processes", so a timed-out probe makes the daemon manager refuse to stop a
daemon it owns, on exactly the slow or loaded machines where it matters. The
Windows probes now carry their own 30s deadline; the POSIX ones keep 5s, which
is ample to read procfs or run `ps`.

test-api (2/3): test_llm_trace::test_disabled_writes_no_rows failed with
`assert 4 == 0` — four calls recorded for its bank despite it disabling its own
engine's recorder. Recorders live in a process-global registry that accumulates:
MemoryEngine.__init__ registers, only close() removes, and a leaked one is still
enabled and still writing to the shared table. That is #2229, which already has
two guards; the autouse one had a hole. It snapshotted `{id(r) for r in
recorders}`, and an id is only unique while its object is alive — a recorder
registered and dropped mid-test can be collected, and CPython hands the same
address to the next one, which then matches the snapshot and survives the
cleanup. Snapshotting the objects compares by identity and keeps them alive, so
no address can be recycled underneath the comparison.

The test also asserts up front that the registry holds only its own recorder, so
a recurrence names the leak instead of arriving as `assert 4 == 0` in a test
about something else.

The Windows flake cannot be asserted directly from CI, so the new test pins the
deadline, which is the part that was wrong. Verified by reintroducing the bug:
back at 5s it fails, with the fix it passes.