[low] tests: cover security_guard daemon-recovery path (re-probe succeeds)

[fentas]

Follow-up from PR #443 (#418) round-2 review.

The re-probe test (daemon_disabled is re-probed …) uses a missing socket, so the re-probe always re-fails — it verifies the increment→reset trajectory but can't assert the recovery path (re-probe succeeds → daemon_disabled stays false AND daemon_trust_seeded re-seeds). Asserting that needs a mock UDS daemon fixture on the Zig side (the security_guard tests currently have none).

Add a lightweight in-test UDS server (or a fixture) that accepts classify (and trust_list) so a test can drive: down → latch → re-probe → daemon back up → daemon_disabled==false + trust seeded. Non-blocking.

[fentas]

Investigated; deferring and leaving open — pending a non-racy security_guard daemon fixture.

Asserting the recovery trajectory (down → latch → re-probe succeeds → daemon_disabled==false + daemon_trust_seeded re-seeds) requires a Zig-side mock UDS daemon that answers classify (and trust_list). The security_guard tests have no such fixture today, and the one attempt at an in-process fake UDS daemon + servicing thread (under #433) proved racy and hang-prone — sticky client connection, server-thread lifecycle hard to bound under the build test runner (which also swallows child stderr), runs alternating pass / assertion-fail / 240 s hang. It was reverted rather than merged as a flaky test.

This is the same harness gap as #461 item 1 (atty-side daemon-verdict integration). Both want a reliable scripted/real-atty-guard driver — most likely in the e2e harness (tests/e2e/) so the daemon→atty path runs out-of-process without in-test thread races. Tracking here until that harness exists; the existing test still covers the increment→reset trajectory in the meantime.