SessionLoop.handleListJobs materializes and sorts all matches before slicing

[nficano]

Summary

Second-pass performance/code-quality audit finding. handleListJobs streams all runtime jobs, filters, sorts the full result, maps every match to JobSummary, and only then slices the requested page.

Evidence

• arcp-runtime/src/main/java/dev/arcp/runtime/session/SessionLoop.java:336 starts building matching from runtime.jobs().stream().
• arcp-runtime/src/main/java/dev/arcp/runtime/session/SessionLoop.java:337 through arcp-runtime/src/main/java/dev/arcp/runtime/session/SessionLoop.java:347 applies filters to every job.
• arcp-runtime/src/main/java/dev/arcp/runtime/session/SessionLoop.java:349 through arcp-runtime/src/main/java/dev/arcp/runtime/session/SessionLoop.java:351 sorts all matches.
• arcp-runtime/src/main/java/dev/arcp/runtime/session/SessionLoop.java:352 through arcp-runtime/src/main/java/dev/arcp/runtime/session/SessionLoop.java:363 maps the entire sorted set to a list.
• arcp-runtime/src/main/java/dev/arcp/runtime/session/SessionLoop.java:378 through arcp-runtime/src/main/java/dev/arcp/runtime/session/SessionLoop.java:383 slices only after the full list exists.

Why it matters

limit controls response size but not server work. A request for a small page still allocates and sorts every visible match, which scales poorly for runtimes with long retention or many active sessions.

Proposed fix

Move paging into the registry/query layer with a stable keyset cursor. Collect limit + 1 summaries after cursor positioning and avoid sorting/mapping rows that cannot appear in the page.

Acceptance criteria

• A small session.list_jobs page does not allocate/map every matching job.
• Cursor ordering and sort ordering use the same stable key.
• Tests or a benchmark cover a large job registry with a small limit.