listJobs snapshots and sorts every visible job for each page

[nficano]

Summary

Second-pass performance/code-quality audit finding. Server.listJobs copies all visible jobs, snapshots every one, sorts the full filtered result, and only then applies cursor and limit.

Evidence

• server/server.go:455 defines listJobs.
• server/server.go:456 through server/server.go:463 copies every same-principal job into a temporary jobs slice.
• server/server.go:464 through server/server.go:471 snapshots and filters those jobs into a second out slice.
• server/server.go:472 through server/server.go:477 sorts the entire output slice.
• server/server.go:478 through server/server.go:483 applies cursor and limit only after the full sort.

Why it matters

Every page request costs O(n log n) over all visible jobs and allocates two slices before pagination. Paginating through a busy runtime repeats the same snapshot/filter/sort work on each page.

Proposed fix

Use a stable keyset cursor based on the same ordering used for the page, and page from an ordered index or bounded scan. Build filter lookup sets once per request and collect only limit + 1 rows after cursor positioning.

Acceptance criteria

• A small page request does not sort or snapshot every visible job.
• Cursor semantics are based on the same stable key as ordering, not a separate field.
• A benchmark or regression test exercises a large job table with limit much smaller than the total.