Simplify and Clarify Job State Model for Improved Consistency and Documentation

Summary

This issue proposes simplifying and clarifying the job state model to reduce ambiguity, remove overlapping meanings, and improve both documentation and implementation.

Proposed changes

• Reduce overlapping terminal states (canceled / terminated)
  Both represent jobs that are intentionally stopped before completion. Unless there is a strong requirement to distinguish user-initiated from system-initiated termination, these can likely be collapsed into a single terminal state (for example, canceled).

• Reduce overlapping dependency states (blocked / uninitialized)
  Both represent jobs whose dependencies are not yet satisfied. The distinction between “created but not evaluated” and “evaluated but still waiting” may not be necessary. We could merge it into a single state that simply means “created but not runnable due to dependencies.”

• Remove disabled as a runtime state
  The disabled state does not describe an execution phase, but rather a configuration/metadata flag. A disabled job means “do not schedule this job,” which is better modeled as a property (for example, enabled = false) instead of a runtime state in the lifecycle.

• Clarify the distinction between ready and pending in the documentation
  The intended behavior seems to be:

  • ready: job has satisfied all dependencies and is waiting in the queue to be claimed by a runner.
  • pending: job has been claimed and is waiting for resources to start running.
    Example wording for pending: “Job was claimed and is waiting for resources to run.”

The issue names no files, tests, or entry points. First locate the current job-state definitions and their usages, then review how documentation describes each state; the work is done only after the state model is agreed and the implementation and documentation consistently reflect it.