session.list_jobs scans and stores every visible job before slicing the page

[nficano]

Summary

Second-pass performance/code-quality audit finding. The Python session.list_jobs handler builds a complete matching list of visible jobs before slicing the requested page.

Evidence

• src/arcp/_runtime/_handler_list_jobs.py:40 calls _filter_jobs(...) and stores the full result in matching.
• src/arcp/_runtime/_handler_list_jobs.py:41 slices matching[offset : offset + limit] only after all matches were collected.
• src/arcp/_runtime/_handler_list_jobs.py:63 creates out: list[Job] = [].
• src/arcp/_runtime/_handler_list_jobs.py:64 through src/arcp/_runtime/_handler_list_jobs.py:71 scans all runtime._jobs.values() and appends every matching job.

Why it matters

A small page request still walks and stores all visible jobs. The offset cursor also makes later pages repeat the same scan from the beginning, so paginating through a large runtime compounds the cost.

Proposed fix

Use a stable keyset cursor and collect only limit + 1 entries after cursor positioning. If stable ordering is required, maintain an ordered index or sort once at insertion time rather than rebuilding every page.

Acceptance criteria

• limit bounds page materialization to approximately limit + 1 jobs.
• Pagination uses a stable cursor that does not require rescanning and storing all prior matches.
• A regression/benchmark covers a large _jobs map with a small limit.