Late-recall regression reports recall instead of recall:late in combined gate #1655

What happened

The independent combined gate for PR #1632 at 458d1be73b513f2b43afebaa544677ac5353d365 failed one session regression on 2026-09-28:

TestARecallThatLandsAfterTheFirstWordRidesTheNextStep
loop_speed_test.go:421: the decomposition names [recall], want the block written down as late
--- FAIL: TestARecallThatLandsAfterTheFirstWordRidesTheNextStep (0.67s)

The session package failed one of eight shards; the eight interface shards and all seven other affected packages passed. Build, static analysis, manual/change-entry checks and all law checks passed. GitHub CI passed the same commit (run), so this observation must not be described as a deterministic reproduction or dismissed as a passing rerun. The independent gate exited 2.

Replication

No model calls are required. Check out the exact published commit, then run the observed gate:

git checkout 458d1be73b513f2b43afebaa544677ac5353d365
GOMAXPROCS=4 GOFLAGS=-p=2 make pr-ready BASE=b267d390078494f659ade14fe8b31daee255771a

The existing fixture can be selected for investigation with:

GOMAXPROCS=4 GOFLAGS=-p=2 go test -count=1 -timeout 15m ./internal/session -run '^TestARecallThatLandsAfterTheFirstWordRidesTheNextStep$'

Its isolated failure frequency has not yet been measured. The fixture emits the first word, delays its first response by 400ms, and requests recall with a 100ms delay. Determine whether the ordering assumed by the fixture is guaranteed before attributing the failure to scheduling or changing runtime behavior.

Where

internal/session/loop_speed_test.go, TestARecallThatLandsAfterTheFirstWordRidesTheNextStep, the paceCompleter/paceAgent fixture and the production recall/first-word boundary they exercise.

Expected behavior and acceptance

• Through the real session submission path with its scripted completer, recall that arrives after the first emitted word is recorded as recall:late, does not cut/re-ask that response, and appears in the next request.
• Preserve all three existing assertions. Use explicit ownership/order synchronization if the fixture is racing; do not merely enlarge sleeps, waive the test or add it to a skip list.
• Establish a before/after reproduction for the actual cause, then pass the affected session suite and combined gate on the corrected revision.
• If investigation finds a user-visible runtime defect, verify the corresponding ordinary workflow and update its manual/change entry. No separate live user-facing recall failure has been established yet.

Batch boundary

The owner froze #1632 and requested an honest review handoff with this failing independent gate disclosed. This issue belongs to the next batch; do not add its fix to the frozen #1632 revision.