Allow opted-in Actions to resume agent threads when they finish

[lastobelus]

Problem

Agents currently have to poll, spend turns sleeping, or ask the user to relay
completion when they start a process that outlives the current turn. LastCode
already owns configured Actions, thread identity, provider sessions, terminals,
and terminal-exit events, but it does not bridge one addressed Action result
back into the originating thread.

This feature should prove that bridge with one narrow, useful tracer before
introducing a general task or orchestration framework.

Proposed delivery

Slice 1: Quick-CI exit tracer

Add a local, per-Action setting, default off:

Allow this Action to resume agent threads

The permission is local LastCode state. A checked-in or imported t3.json
cannot enable it. Enabling it makes the Action eligible; it does not make normal
UI clicks or arbitrary terminal exits resume threads.

An agent explicitly invokes one dedicated, resume-capable LastCode MCP tool for
one configured Action. LastCode:

1. derives the originating thread and provider session from the authenticated
   MCP invocation;
2. opens a dedicated thread-scoped terminal and attaches its exit listener
   before launching the configured command;
3. returns an arming receipt immediately and instructs the agent to finish
   its current turn; and
4. after the Action reaches a terminal state and the thread is idle, starts
   exactly one follow-up turn on that same thread.

The arming receipt is a structured acknowledgement containing a server-generated
run ID, the wake condition, and the first-cut durability boundary. armed
describes the one-shot wake registration, not whether the process is still
running. It is not a polling handle, and the MCP surface supplies no wait or
status-poll operation.

The automated follow-up must be represented as LastCode machine activity, not
as a fake human message. Provider input contains only fixed LastCode-authored
control text, server-generated identifiers, and validated status values.

Output handoff

On exit, LastCode finalizes a bounded output artifact under T3 home in a
server-generated thread/run directory. The artifact contains a size-limited
suffix of terminal output after replay-unsafe control sequences are removed.
The wake supplies an artifact descriptor with its path, byte and line counts,
completion state, and truncation state, plus the exit code or signal and
duration.

No terminal output or generic last-line preview is inserted into the automatic
provider input. The resumed agent decides whether and how much of the completed
file to read. Its contents remain untrusted data.

The current Action terminal is a PTY and exposes a combined output stream. One
combined artifact is sufficient for the tracer. Separate stdout and stderr
artifacts would require a runner that pipes and tees both child streams back
into the visible terminal and are not required for this slice.

Retain artifacts through thread archive because archive is reversible. Delete
them with permanent thread deletion. Archived threads must not be resumed
automatically; the exact treatment of an Action still running when its thread
is archived must be fixed before implementation.

Slice 2: restart durability

The first tracer may truthfully report durability: current_lastcode_process.
A LastCode restart may terminate the Action and lose its in-memory wake
registration; persisted terminal evidence and a manual user resume are the
initial recovery.

The required second cut makes Action execution and its wake durable across a
full LastCode restart. Its finite test is:

1. start an Action and finish the originating turn;
2. restart LastCode while the Action is running;
3. verify that the Action continues;
4. recover a completion that occurs during or after the restart; and
5. resume the originating thread exactly once when it is eligible.

Choose the smallest reattachable process-ownership and persisted-correlation
model that passes this test. Do not use this requirement to build a general
scheduler.

Slice 3: retention controls

Because archived threads may remain indefinitely, LastCode Settings should
report the count and disk use of completed Action artifacts and provide an
explicit cleanup command for artifacts belonging to archived threads. Cleanup
excludes running Actions and pending wakes and warns that an unarchived thread
will no longer have those logs.

An optional automatic retention policy may follow and defaults off. It is not a
prerequisite for the Quick-CI tracer.

Acceptance criteria

• One real, locally opted-in Quick CI Action runs in a real LastCode-hosted
  terminal.
• The originating agent turn ends before the Action finishes and consumes no
  polling turns while waiting.
• The Action's terminal result and idle-thread state produce exactly one
  follow-up turn on the originating thread.
• Ordinary Action clicks, unrelated terminals, and Actions without the local
  permission never arm a wake.
• The arming receipt and visible machine activity truthfully distinguish the
  automated source from a human message.
• Automatic provider input contains structured result metadata and an artifact
  descriptor, not terminal output.
• The output artifact is readable on demand, bounded, marked as untrusted, and
  retained through archive until explicit cleanup or permanent thread deletion.
• The first-cut restart limitation is visible and recoverable; the second-cut
  restart test above subsequently passes.
• LastCode Settings eventually exposes artifact size and safe manual cleanup.

Explicit non-goals

• A general task database, scheduler, or orchestration framework.
• Arbitrary-command adoption or waking on every terminal exit.
• Polling-based MCP Tasks emulation.
• Readiness and input-required protocols, development-loop supervision, or
  Markover feedback wakeups in the first tracer.
• Provider-neutral adapter machinery before the Codex-backed tracer proves the
  process-to-thread seam.
• Separate stdout/stderr capture in the first slice.

MCP Tasks remains a later compatibility target when relevant hosts expose the
extension; the local tracer does not depend on host Tasks support.