[Bug]: Lark human-gate full-public smoke times out and blocks release qualification on main #6887

Preflight

• I searched existing issues and discussions for this behavior.
• This report is not an unpatched security vulnerability.
• The report and attachments contain no credentials or private/internal material.

Issue origin

Observed or reproduced in a real environment.

LoopX version or commit

a72dcb21a (current main at report time). The first failing scheduled run observed was dc9fdbb51.

Host or runtime surface

Codex CLI (the smoke uses the production Codex app-server protocol through a fake CLI).

LoopX area

Build, packaging, installer, or CI. The failing check belongs to the bundled Lark extension's public-smoke coverage.

Problem

Impact: the daily Full Public Smokes release-qualification fleet cannot reach a green readback on current main, so a release candidate cannot clear the documented manual full-public qualification step.

Release readiness requires an exact-candidate full-public sweep and readback (docs/development/testing-and-quality.md). The scheduled run below deterministically fails check 25 in shard 3, and smoke-fleet-health consequently reports the fleet as not ready. This affects release maintainers and every release candidate built from current main; it does not indicate that production Goal Channel notifications are broken.

Evidence from the current scheduled failure:

• Run: https://github.com/loopx-project/loopx/actions/runs/39165718889 at dc9fdbb51
• Failed shard: https://github.com/loopx-project/loopx/actions/runs/39165718889/job/117788247282
• Failed check: examples/lark-goal-channel-human-gate-delivery-smoke.py, check index 25
• Result: status: failed, returncode: 1, duration_seconds: 33.44
• Error: gate_selection (steward_notice_unavailable)
• Fleet health: https://github.com/loopx-project/loopx/actions/runs/39165718889/job/117790917082 failed with the fleet not ready

The same check passed in the preceding scheduled run (39068476762, check 25, duration_seconds: 13.552), so this is a regression rather than a pre-existing flake.

Minimal reproduction

On a supported Linux host (the environment used by the public fleet):

git checkout a72dcb21a
python3 examples/lark-goal-channel-human-gate-delivery-smoke.py

The smoke exits non-zero after roughly 30 seconds. A Windows-adapted copy using executable launchers (no change to the smoke's runtime calls) reproduces the same result on a72dcb21a.

Expected behavior

The smoke should pass for both file and sqlite providers, printing two lark-goal-channel-human-gate-delivery-smoke ok lines. Check 25 should be passed, and the fleet receipt should be able to report ready.

Actual behavior

The fake Codex app-server never answers the new thread/name/set request. The production adapter waits for the response, times out, closes the session, and the Goal Channel layer reports the misleading steward_notice_unavailable blocker before any IM delivery is attempted.

Sanitized trace:

thread/start
thread/name/set {"threadId": "synthetic-notice-thread", "name": "LoopX Chat"}
...
loopx.chat_agent.CodexChatTimeoutError: Codex app-server timed out.
...
"blocker": "steward_notice_unavailable"
"stage": "gate_selection"

Diagnostics

CodexAppServerAdapter.start in loopx/capabilities/native_chat/codex_adapter.py now names a newly managed thread through thread/name/set before publishing the binding. The fake Codex in examples/lark-goal-channel-human-gate-delivery-smoke.py only handles initialize, thread/start, thread/resume, and turn/start; every other method is silently ignored. The request therefore has no response and hits the 30-second app-server response timeout, which is mapped to steward_notice_unavailable even though the failure occurs while preparing the synthetic notification model, not while delivering through Lark.

The same protocol acknowledgement was already added to another fake app-server fixture in PR #6849 (tests/test_chat_manager_inspection.py), so the production request itself is expected; this smoke's fake is the stale side.

Additional context

• The request was introduced by PR fix(chat): preserve empty managed Codex conversations across restart #6793.
• PR test(chat): acknowledge named manager threads in the real fixture #6849 fixed the same fixture gap in tests/test_chat_manager_inspection.py.
• The smallest repair is to acknowledge thread/name/set in this smoke's fake Codex and fail fast on unexpected request methods so future protocol drift cannot turn into a 30-second timeout.

AI disclosure: this report was drafted with AI assistance at my request, under my direction and review.