[factory] Canary 2: controlled probe — does a new candidate land in lifecycle-terminal or not-ready?

[khaliqgant]

Controlled probe for factory#355. This issue exists to be counted, not worked.

Hypothesis under test

Two completed sweeps show not-ready and parked-dependency unchanged (21 and 1) while candidates and lifecycle-terminal each rose by exactly one:

	08:35Z	15:17Z
candidates	27	28
lifecycle-terminal	5	6

That suggests newly-eligible work units are marked lifecycle-terminal on arrival, rather than the terminal set being historical residue. If true, no new work can ever dispatch and the backlog only grows — which would explain the whole outage.

The probe

This issue is filed deliberately at a known time, matching the deployed gate exactly:

• label factory ✓
• title prefix [factory] ✓
• routed repo (factory is in repos.names) ✓
• never dispatched, no factory:* lifecycle label

Predictions for the next completed, non-deferred sweep:

• If the hypothesis holds: candidates 28 → 29 and lifecycle-terminal 6 → 7, with not-ready still 21.
• If it is wrong and terminal records are historical: candidates 28 → 29 and not-ready 21 → 22, with lifecycle-terminal unchanged at 6.

Those outcomes are mutually exclusive and one sweep separates them. Read only samples where discoveryDeferred is absent — deferred attempts report candidates: 0 and mean "did not look", not "found nothing".

Note sweeps take ~39 minutes (lastDurationMs: 2338447 observed), so the answer is roughly one sweep away, not immediate.

Deliverable

None. Do not implement anything for this issue. If an agent picks this up and starts work, that is itself a finding worth reporting on #355 — it would mean dispatch is working and the counters are lying.

Safety: public repo, no customer names, no credentials, no exploit paths.