fix(replay): stop the replay tick starving on an unclassified pending capture

[try-works]

Why

Two defects on the path from a live request to a learner pack. Both were invisible because the tests stubbed a shape production does not have.

1. The replay tick starved on an unclassified pending capture

The tick builds its capture set from the sidecar's cheap pending view and then adds the rich corpus read only for captures the pending view does not already contain. Only the corpus read carried the route classification, so deduping by capture ref discarded the classified row and kept the unclassified one: the ownership filter matched nothing, the tick threw NoReplayableRequest on every tick for ever, no replay job was created, no disposition was written and the pending row was never retired.

Whenever the focus task's captures all fit inside the pending scan window - a task that has just started being routed, or any small state root - nothing can ever be dispatched. On a mature root the corpus read usually supplies captures outside the window, which is why the defect stayed hidden on stage and in production.

A capture that is already present is now enriched from the corpus read instead of dropped, so an unclassified row can never mask the identity the corpus read proved it has. A capture that is already classified keeps the cheap row, because then the two views agree.

2. The comparison never named the task family

The supervised-replay comparability read capture.taskTypeId straight off the capture record, while roleId and taxonomyVersion next to it have always been read through a fallback to classification. A comparison built from a capture that records the family only where the capture contract puts it was therefore finalized with taskTypeId: null.

The knowledge worker scopes a comparison by (comparability.roleId, comparability.taskTypeId) and excludes an incomplete scope fail-closed as incomplete_scope. Those groups were durably recorded and then invisible to both the admission floor and the ranking - so no RouteLadderPackV1 could ever be written for the task, and the learner reported a task that never accumulated evidence instead of reporting an error.

readCaptureTaskTypeId reads the family exactly like its two siblings. Measured: 2 of 8 finalized groups on the dev root carried taskTypeId: null while their source captures decrypted to writer.summarize.

Diagnostics

readRouteReplayableCaptures expressed its 23 admission conditions as one boolean chain behind a bare continue, so a rejected capture surfaced only as an unattributable NoReplayableRequest. Each condition is now named once in an ordered gate table, and ROLE_MODEL_FOCUS_DIAG prints the gates that dropped each capture; the corpus-unavailable path logs its own cause instead of collapsing to null. This is what made the second defect findable.

The trial artifact readback added earlier for a misdiagnosis is removed: the transcript was never the problem. The capsule read already resolves it out of the artifact store, so the refs-only design holds without a second reader.

Tests

• run105-review-dispatch.test.ts: a cold-start regression test that models the real interaction - the same capture ref in both views with identity only in the corpus read. The suite previously stubbed the two readers independently and almost always left the pending view empty, so it could not express production's state.
• run104-r22-learning-scope-travel.test.ts: three cases pinning the family reader, whose fixtures previously always declared a flat taskTypeId.
• 99 tests pass across the five affected suites; tsc --noEmit and biome check clean.

Verification

Rebuilt paired distribution (b5a11efc, sidecar 881d393888adbe1f) launched on :3458: the first tick owned and dispatched a capture, 8 captures reached the durable replayed disposition, the evaluation core finalized comparison groups with full comparability identity, and the admission floor reached 5 eligible effort-matched comparisons at mean confidence 0.849 for the pair (deepseek-v4-pro-max, deepseek-flash-max).

Docs

docs/operations/route-capture-and-replay-queues.md (private) is the canonical map; .recursive/STATE.md and .recursive/DECISIONS.md record and reference it.

Out of scope

Recorded as open findings in the doc, not fixed here: the replay arm is chosen without consulting reasoning effort (so on a configuration with a single low-effort variant every comparison sourced from a max-effort endpoint is voided arm_effort_mismatch), the learner sweep that materializes a pack is skipped while a long replay is in flight, and a capture whose replay keeps failing keeps re-entering the queue. No stage, main or release promotion.