fix(todo): align in-progress guidance with concurrent work

[tossp]

Issue for this PR

Closes #44221

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

The todowrite description required exactly one in_progress item even though the runtime supports multiple. In a GPT-5.6 Sol session, this was interpreted as a scheduling constraint and caused independent ready work to be serialized.

This PR updates only the model-facing description:

• mark every task actually running as in_progress, including concurrent or delegated work;
• remove the single-active-task upper limit;
• keep at least one task in_progress while work remains.

No runtime or UI behavior is changed.

How did you verify your code works?

git diff --check passes.

No functional tests were run because this is a text-only tool description change and does not alter runtime behavior.

Screenshots / recordings

Not applicable; this is not a UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[Enough1122]

AI code review — automated review for reference, author can ignore or act on any point.

Reasonable prompt-hygiene fix: if the runtime already tolerates multiple in_progress items, telling the model "exactly ONE at a time" invites it to serialize independent ready work, as described. Text-only change to packages/opencode/src/tool/todowrite.txt, no behavioral risk.

Suggestions:

1. In the States section (hunk @@ -17,14, changed line 20), consider adding a short guardrail so the loosened rule doesn't swing too far: something like "mark only tasks genuinely executing now as in_progress — not tasks merely planned next." Without it, some models may over-mark everything in progress, which degrades the same scheduling signal this PR tries to restore.
2. Worth a quick grep for sibling constraints ("one at a time", "exactly one") in other tool descriptions or docs so guidance stays consistent across prompts.
3. If any test snapshots the todowrite prompt text, it will need regeneration; otherwise the verification approach is appropriate for a string-only change.