Automatically resume agent thread on CI/check failure

Problem

T3 Code can already work with GitHub/PR state, but CI handling still appears to rely on the agent actively polling/checking status.

For long-running coding tasks, it would be much more useful if T3 Code itself could monitor the PR/check state and push failures back into the existing agent thread when they happen.

This is especially important for projects where CI runs tests that cannot realistically be reproduced in the local development environment, for example:

• architecture-specific builds/tests (ARM64, different CPU features, etc.)
• OS-specific jobs (Linux/macOS/Windows)
• containerized or service-heavy integration environments
• tests that depend on infrastructure, secrets, external services, or hosted runners
• larger CI matrices that would be impractical to run locally

In those cases, CI is not just a final verification step; it is effectively part of the development feedback loop. The agent needs the failure output in order to continue the task.

Proposed behavior

When a thread is associated with a branch/PR:

1. After the agent pushes a commit, monitor the checks for that PR/HEAD SHA.
2. If a check fails, fetch the failed check metadata and relevant logs/output.
3. Inject the failure into the existing thread as new context/event.
4. Automatically resume/wake the agent so it can diagnose and fix the failure.
5. After the agent pushes a new commit, ignore failures/results belonging to obsolete SHAs.
6. Continue until the latest commit is green, or until the agent/user stops the workflow.

Why

This would avoid spending agent turns repeatedly polling GitHub and would make the workflow genuinely event-driven:

push -> CI runs -> failure arrives -> existing agent thread resumes -> fix -> push -> CI reruns

The important distinction is that T3 Code should be the event source here rather than requiring the agent to periodically ask GitHub whether CI has completed.

It would also make external signals such as CI failures behave more like first-class inputs to a running agent session, which seems useful beyond GitHub Actions as well.

Start by tracing the existing GitHub/PR state handling and the lifecycle of an agent thread, including how the current polling or status checks work. Then identify the entry points for push events, check results, failed-check metadata, and thread resumption; done means failures reach the existing thread, obsolete SHAs are ignored, and the workflow continues until green or stopped.