09 — Workflow Orphan Remediation v2

v_workflow_orphan_remediation_v2 rebuilds the queue post-candidate: every one of the original 143 objects now rolls up to a candidate + residual state.

Original 143 → residual states

residual_state	objects	meaning
RESOLVED_CANDIDATE	69	mapped to a candidate/component RP can list
RESOLVED_NOT_PROCESS	40	OS-level (29) + shared-lib cron-env (8) + noise (3) — explicitly accepted out of scope
AWAITING_EVIDENCE	23	dot/bin reconcile (18) + throttled DB jobs (4) + infra config (1)
AWAITING_OWNER	11	docker runtime services
total	143

Before vs after

• Before: 143 OPEN rows, undifferentiated "orphan", no disposition, no owner of the decision.
• After: 109 of 143 (76%) are RESOLVED (candidate-visible or explicitly not-a-process). Only 34 remain actionable: 23 awaiting evidence (AI-actionable: pull the truncated cron target / a runtime run-row) + 11 awaiting an owner (docker — owner decides which containers are managed processes).

Why the residual isn't zero (honest)

• 18 dot/bin executables need 1:1 reconciliation to dot_tools (register or retire) — each is a small AI-actionable task but touches the birth-gated dot_tools, so deferred.
• 4 throttled docker exec psql cron jobs have their target function truncated in the snapshot (90-char capture) — need a fuller command capture or a runtime run-row to name the DB side-effect.
• 11 docker services are genuinely an owner decision (which containers count as managed workflow processes vs pure infra).

Residual queue is now small, labeled, and each item has an exact next action.