s17: IDLE teammates cannot resume their own in-progress tasks

[yuhuping]

Bug

In the teaching implementation of s17_autonomous_agents/code.py, a teammate can leave tasks it already owns stuck in in_progress and then exit after the 60-second IDLE timeout.

Cause

idle_poll(name, ...) only calls scan_unclaimed_tasks(). That scan accepts only tasks that are:

• status == "pending"
• unowned
• dependency-ready

It never looks for tasks with status == "in_progress" and owner == name.

Therefore, after a WORK phase ends without a tool_use response (for example, the model returns ordinary text before it has called complete_task), the outer loop enters IDLE. The teammate cannot rediscover its own unfinished task, waits for IDLE_TIMEOUT = 60, sends a final summary, and exits. The task remains owned and in_progress.

Reproduction

1. Create a pending task and start a teammate.
2. Let the teammate claim the task but end a WORK phase before marking it complete.
3. Observe that the task is still in_progress with that teammate as owner.
4. The teammate polls for 60 seconds, finds no unclaimed work, and exits instead of resuming its owned task.

Expected behavior

During IDLE, after handling inbox messages and before claiming new work, a teammate should resume one of its own in_progress tasks. It should return to WORK with that task injected into its messages, rather than timing out.

Minimal fix

Add a helper such as scan_resumable_tasks(owner) to find in_progress tasks owned by the current teammate. In idle_poll, prioritize one resumable task before scan_unclaimed_tasks() and append a message like:

{"role": "user", "content": "<resume-task>Task ...</resume-task>"}

I verified this with a regression test: when Alice owns an in_progress task and another pending task exists, idle_poll("alice", ...) returns "work", injects the owned task, and leaves the pending task unclaimed.

This is a teaching-version bug report; it is not a claim about the production Claude Code scheduler.