Punca Mengapa Transaksi Memeriksa Apabila Sebelum Melakukan Transaksi Ditawarkan Oleh Mengelakkannya

Phase 1 of the #632 design (see the design comment on #632). No behaviour change.

Many consumers key behaviour on hand-written lists of jobs.status values. Each list answers a different underlying question:

Examples:

the telegram_photo_terminal_cleanup trigger;
budget continuation (budget_continue_current, _offer_budget_continue);
login reopening (_login_reopenable, _settle_browser_login);
action continuation (_queue_action_continuation, resume_action_work);
settings and native-handoff resumption (mcp_setup_recoverable, resume_settings_work, settle_native_handoffs, resume_ready_native_work);
retry and usage-limit recovery (safe_retry, reply_controls, _validate_usage_limit_recovery, the Telegram callbacks);
upkeep and self-review eligibility;
preparations;
saved-result selection;
success reactions.

Because these questions share one column, phases 2–3 cannot change how status is decided without breaking unrelated consumers.

Change

Replace the status lists in consumers with a few named predicates, one per underlying question, in one module. Each predicate is defined from today's status values plus the records the consumer already reads, so every consumer behaves exactly as before.
Where two consumers ask the same question with different lists, keep both behaviours and name the difference. Do not unify them silently. List each such difference in the PR for a later decision.
The SQL trigger keeps its own SQL. Document the predicate it mirrors, and add a test that it and the Python predicate agree.
Nothing in the schema changes, and no stored rows are rewritten.

The whole existing suite passes unchanged. Do not edit any existing test assertion, except to import a renamed symbol.
New tests pin each predicate against the status values and records it covers.

Problem: one stored value carries four meanings.
External: OpenAI Agents SDK RunResult (final output vs. interruptions vs. exceptions), OpenHands agent states (FINISHED / AWAITING_USER_INPUT / ERROR), LangGraph run status vs. graph state, and Claude Agent SDK ResultMessage vs. is_error. All keep run state apart from tool-call failures and from awaiting input.
Decision: Adapt that separation first at the read side, as predicates, without new storage.
Internal: the existing status lists and work_waits_for_owner / _work_has_unknown_effect.

Not escalated: no behaviour, authority or record change.

refactor: consumers ask what a Work's status means through named pred…