handleListJobs sorts all global jobs before pagination

[nficano]

Summary

Second-pass performance/code-quality audit finding. Runtime handleListJobs builds all authorized candidates from server.globalJobs, sorts the whole candidate array, and only then paginates.

Evidence

• packages/runtime/src/server-subscribe.ts:39 builds candidates with buildListJobsCandidates(...).
• packages/runtime/src/server-subscribe.ts:40 sorts the entire candidate array.
• packages/runtime/src/server-subscribe.ts:41 through packages/runtime/src/server-subscribe.ts:45 paginate only after sorting.
• packages/runtime/src/server-subscribe.ts:65 initializes out: JobListEntry[] = [].
• packages/runtime/src/server-subscribe.ts:66 through packages/runtime/src/server-subscribe.ts:79 scans every server.globalJobs.values() entry and appends every match.

Why it matters

limit bounds the response, not the runtime work. A small page request over a large retained job set still scans, allocates, and sorts every authorized match. Repeated pages repeat the same work.

Proposed fix

Use a stable keyset cursor and collect only limit + 1 rows after cursor positioning. If deterministic ordering is required, maintain a created-at/job-id index or use a bounded selection strategy instead of sorting the full set per request.

Acceptance criteria

• A small session.list_jobs page does not allocate/sort every authorized job.
• Cursor ordering uses the same stable key as the list ordering.
• A regression or benchmark covers many globalJobs with a small page limit.