session.list_jobs materializes every visible job before applying the limit

[nficano]

Summary

Second-pass performance/code-quality audit finding. The F# runtime handles session.list_jobs by filtering the full principal-visible sequence into a list and only then truncating to the requested limit.

Evidence

• src/Arcp.Runtime/ArcpServer.fs:326 starts the filtered pipeline from jobs.AllForPrincipal ctx.Principal.Id.
• src/Arcp.Runtime/ArcpServer.fs:328 through src/Arcp.Runtime/ArcpServer.fs:336 applies the request filters.
• src/Arcp.Runtime/ArcpServer.fs:337 calls Seq.toList, forcing all matching rows into memory.
• src/Arcp.Runtime/ArcpServer.fs:339 through src/Arcp.Runtime/ArcpServer.fs:342 applies List.truncate after that full materialization.
• src/Arcp.Runtime/ArcpServer.fs:348 always returns NextCursor = None.

Why it matters

The request Limit does not bound runtime work. A client asking for 10 jobs from a principal with many jobs still scans and allocates every matching job before dropping almost all of them. The missing cursor also prevents callers from using small pages to keep runtime work predictable.

Proposed fix

Keep the filtered sequence lazy until page selection, support a stable cursor, and take limit + 1 rows to decide whether NextCursor exists. If ordering is required, define a stable key such as (created_at, job_id) and avoid rebuilding a full list for every page.

Acceptance criteria

• session.list_jobs supports a cursor and sets NextCursor when more rows are available.
• A small Limit avoids allocating the full matching job set.
• Tests cover multiple pages and a large matching job set.