[Bug]: absolute fixture dates make the Lark manager-context tests expire after seven days

[DJC1412]

Problem / 用户影响

tests/extensions/test_lark_goal_topic_runtime.py carried absolute event timestamps (2026-09-13T05:59:00Z / T06:00:00Z) for the manager-context fixtures. Manager context is bounded by MANAGER_CONTEXT_MAX_AGE = timedelta(days=7) (loopx/extensions/lark/manager_context.py:28), evaluated against datetime.now(UTC) when no now is injected. So the fixtures stayed valid for exactly seven days after they were written and then failed for everyone, on every branch, with no code change in between.

This is not a product defect: the retention rule is intended. The test-suite defect is that a durable rule is pinned by a calendar rather than by an injected clock, so main goes red by itself and every open pull request inherits the failure.

Reproduction and verified scope

Bracketed by the repository's own CI history, with no other change between the two runs:

• python-tests run 35490703890, main head 361347713, created 2026-09-20T05:03Z → all four shards report 0 failures in test_lark_goal_topic_runtime (its only failure that day was tests/canary/test_maintainability_ratchet.py).
• python-tests run 35494985951, main head 4eb6ea9ee, created 2026-09-20T06:43Z → test_manager_captures_unaddressed_context_without_granting_turn_authority and test_manager_authorized_turn_quietly_recovers_history_as_context both fail, assert 0 == 1 on context_material_count.

2026-09-13T05:59:00Z + 7 days = 2026-09-20T05:59:00Z, which falls between those two runs — the pass/fail boundary is the fixture date expiring, not a merge.

Same result locally on a clean origin/main worktree with no changes applied: pytest -q tests/extensions/test_lark_goal_topic_runtime.py → 2 failed, 49 passed, and the two names above are the failures. The assertion that trips first is:

E   AssertionError: assert [{'message_id': 'om_context_only', 'create_time': '…', …}] == [ … ]
    At index 0 diff: … != …
tests/extensions/test_lark_goal_topic_runtime.py:416

…which is the second symptom of the same choice: the expected material dictionary repeats the literal timestamp, so the two copies must match character for character.

Expected behavior / Acceptance criteria

• The manager-context fixtures in tests/extensions/test_lark_goal_topic_runtime.py express event time relative to the run, so the suite does not change verdict because wall-clock time passed.
• Repeated evaluations of one fixture timestamp are equal, so a captured material and the expected payload still compare equal.
• pytest -q tests/extensions/test_lark_goal_topic_runtime.py passes today and on any later date, and tests/extensions stays green.

Proposal

One test-only change: a _fixture_time(minutes_ago) helper in that module, whole-minute resolution so two calls for the same logical event compare equal, replacing the seven literals (60 minutes for the authorized turn, 61 for the context it consumes, preserving their order). No production behavior, schema or authority change; the 7-day rule itself is untouched.

One thing this deliberately does not claim: it does not add a direct test of retention_expired. Reaching that branch through the shipped path means capturing material older than the collector's own seven-day lookback, so such a test would pass for a second reason and certify nothing. Pinning the rule honestly needs an injected now at the process_lark_goal_topic_event boundary, which is a production-signature question rather than a fixture fix.

Validation

uv run --extra test python -m pytest -q tests/extensions/test_lark_goal_topic_runtime.py and … tests/extensions, plus python -m py_compile and loopx check --scan-path tests/extensions/test_lark_goal_topic_runtime.py.