Optimize /api/runs/list job loading

[peterschmidt85]

Fixes #3983

Problem

/api/runs/list powers both the Runs UI and dstack ps. UI/CLI list views normally need only the latest job submission, but the server still eager-loaded the full RunModel.jobs history and trimmed it later during response serialization.

On runs with many retries/submissions, one page could materialize tens of thousands of JobModel rows. Admin/all-project requests also had extra overhead because the service loaded accessible projects into Python and filtered runs with a large project_id IN (...) list.

Fix

• Stop eager-loading RunModel.jobs in the runs-list path.
• After selecting the requested page of runs, load only the job rows needed for the response.
• When job_submissions_limit is set, load the latest N submissions per (run_id, replica_num, job_num) with a SQL window query.
• Also load the latest terminated submission with a termination reason per logical job, so status messages such as retrying stay correct without loading full history.
• Replace Python-built project ID lists with direct project lookup/subqueries for single-project, admin all-project, and member all-project paths.
• Ensure lightweight UI/CLI list callers pass job_submissions_limit=1.