test(mem0): lock the D-7 interlock's absent-capture fail-safe

[Kyzcreig]

What

Adds two regression tests pinning resolve_capture()'s final
return "auto", "default" — the fleet-wide fail-safe that keeps the D-7
interlock engaged on any profile whose mem0.json omits a capture key
(that is every non-root profile in this fleet).

Test-only. plugins/memory/mem0/__init__.py is byte-identical to the base commit.

Why (measured)

Filed from kanban card t_760693df, which asserted the D-7 interlock was
disarmed on 9 worker profiles because the profile mem0.json lacks a
capture key. That mechanism is falsified — absent config resolves to
("auto", "default"), i.e. capture ON, so the interlock engages. The card
had the polarity backwards; the card's prescribed fix (resolve the ROOT
mem0.json instead) measured inert: 0 of 10 profiles change their
capture_is_on decision.

But the audit did find one real, unguarded invariant. The whole fail-safe is a
single literal, and nothing tested it:

mutate  return "auto", "default"  ->  return "off", "default"
result  28/28 existing tests still pass
effect  D-7 interlock silently disarmed on every profile lacking a capture key

Verification

run	result
clean tree	17 passed (was 15)
mutant M1 (auto->off in the default return)	2 failed, 15 passed — exactly the 2 new tests
mutant M2 ("auto" dropped from _CAPTURE_ON)	4 failed, 13 passed (2 new + 2 pre-existing)
scripts/run_tests.sh tests/plugins/memory/	22 files, 449 passed, 0 failed

Reviewer note

The 2 new tests are the entire behavioural claim. M1 is the mutation they were
written to catch; it passed 28/28 before this commit.