Human-review queues need separate decision-readiness and acceptance gates

Observed 2026-09-04 in e3-solutions/theft while implementing COR-4050 / PR #797.

Reusable design finding: a human adjudication queue needs at least two distinct predicates. Decision readiness answers whether all required participant work and asynchronous analysis have reached a terminal state, so the item can be shown to the reviewer. Acceptance eligibility answers whether the settled evidence is positive enough to permit approval. A completed negative result, provider failure, or timeout can therefore be decision-ready while approval remains disabled and rejection stays available. Missing or processing evidence is neither.

Project decision readiness before count/order/pagination, but keep acceptance authorization as an authoritative transactional recheck at mutation time. This avoids hiding negative cases, avoids implying support assistance is the customer decision, and keeps pagination bounded.

Source provenance: repository source and tests on commit a7dcd0e3, reviewed by three independent code-review agents and validated by PR CI including the Postgres integration gate.