[BUG] RemoteTrigger action=list returns has_more/next_cursor but ignores the cursor argument, so routine lists beyond 20 cannot be paged

## Summary

`RemoteTrigger` with `action=list` returns 20 routines plus `has_more: true` and a `next_cursor`, but passing that `next_cursor` back as `cursor` returns HTTP 200 with **exactly the same first page** (same ids, `created_at`, prompts, same byte size). There is no way to retrieve routines 21+ from Claude Code. Any tool that treats "same page returned" as "last page" silently publishes an incomplete list as complete.

## Steps to reproduce

1. Have more than 20 routines on the account (observed with 20+).
2. Call `RemoteTrigger` with `{"action": "list"}`.
- Response: `data` has 20 entries, `has_more: true`, `next_cursor: ""`.
3. Call `RemoteTrigger` with `{"action": "list", "cursor": ""}`.
- Expected: page 2 (routines 21+), or an error if `cursor` is not accepted for `list`.
- Actual: HTTP 200, identical to the step 2 response (first element id / `created_at` / prompt match; response size identical, ~397 KB in our case).

The tool description documents `cursor` for `list_runs` / `get_run_log`; if `list` is intentionally not pageable, then `has_more` / `next_cursor` should not be returned for it, or `list` should accept a page size / cursor. Either way, the current combination makes the full routine set unreachable.

## Environment

- Claude Code CLI on WSL2 (Linux 6.18, Ubuntu), interactive session with Fable 5.1, 2026-09-08
- Observed from a scripted skill that lists routines to count scheduled runs per month (open-source tool AAINC-LAB/cc-usage-insights); the tool now marks such lists `pages_complete: false` and degrades to a partial result.

## Impact

Any consumer that needs the complete routine inventory (audits, usage analytics, cleanup scripts) is capped at 20 and cannot tell which routines are missing.

Related: #24785 / #39586 (MCP `tools/list` `nextCursor` not followed) look like the same class of issue on a different surface.

Start by reproducing RemoteTrigger with action=list, first without cursor and then with the returned next_cursor; compare the routine IDs and response metadata. Read the handling for list_runs and get_run_log cursor parameters to determine whether list is intended to paginate. Done means page 2 is reachable through cursor pagination, or list no longer advertises unsupported has_more and next_cursor fields.

Written by the indexing model from the issue text.