fix: harden task listing against partial and out-of-range results

[alDuncanson]

Follow-ups from #112, found while reviewing the merged ListTasks implementation.

Partial listings were indistinguishable from complete ones

list_all_tasks has three defenses against a misbehaving server, and all three ended the crawl by returning whatever had accumulated. A caller got a short list with no way to tell it apart from a genuinely complete one.

It now returns a TaskListing — the tasks plus a truncated flag:

• CLI text: a trailing Warning: listing stopped early; showing N task(s), which may not be all of them.
• CLI --output json: a truncated field in the envelope
• CLI --output ndjson: a trailing {"type": "truncated", "count": N} record, matching how error records already work
• MCP list_tasks: a truncated field alongside count

The token guard missed cycles longer than one

The loop only stopped when a server handed back the token just sent. A server alternating A → B → A never repeats consecutively, so it ran to the 1000-page cap. The loop now stops as soon as a page contributes no new task while still offering a token, which subsumes replayed pages and token cycles of any length.

The hardcoded default page size was based on a wrong premise

The old comment said servers "commonly reject a zero page size and some treat an unset field as zero, so always send an explicit one," and sent 50 whenever the caller omitted it.

page_size and history_length are proto3 optional fields with real presence. Leaving them unset omits them from the wire entirely — it does not send zero. Confirmed against a live agent: an unset page size returns the full listing, while an explicit 0 is rejected with minimum page size is 1. The default is gone; omitting the flag now lets the server choose, which is what the docstring always claimed.

Validation was duplicated and incomplete

Three copies of the page-size check lived in the service, the CLI, and the MCP tool. They are now validate_page_size and validate_history_length in common/input_validation.py, with a label parameter so the CLI still names the flag the user typed while details.field keeps the machine name.

Two gaps closed along the way:

• page_size above 100 is now rejected locally. The spec bounds a page to [1, 100]; previously a caller paid a round trip to learn that.
• get_task never validated history_length at all.

Testing

Full suite green (520 passed), plus ruff, format, and ty.

Exercised end to end against a live A2A agent (SDK DefaultRequestHandlerV2 + InMemoryTaskStore, JSON-RPC):

• task list with and without --page-size, including real multi-page crawls — a paginated listing returns the same set as an unpaginated one
• Bounds probed directly against the server: 0 → minimum page size is 1, 101 → maximum page size is 100, 100 → OK, unset → OK. The new local checks match the server exactly.
• Truncation confirmed live: capped at 2 pages of 2, a 6-task agent returns 4 tasks with truncated=True; uncapped returns 6 with truncated=False
• MCP list_tasks, get_task, send_message against the same agent, plus all three validators rejecting correctly
• CLI task get, --status filtering, --history-length, and ndjson output

The TUI path is unchanged by this PR and has not been manually exercised.

🤖 Generated with Claude Code