Optional: Resolve job reference data via per-page id__in batch-fetch

[camd]

Summary

Drops the job_type, job_group, and machine_platform joins from the jobs-list
query (JobsViewSet and JobsProjectViewSet) and instead resolves those values
from a per-page id IN (...) batch-fetch scoped to the FK ids actually present on
the page. Output is unchanged.

This is filed as Optional on purpose — see "Scope / how to weigh this" below.

Why

The jobs-list query joins job_type, which on production is a large,
churny reference table (~70k live rows; the id sequence has advanced well past
that due to cycle_data deletions). Because of its size, the planner builds a
hash over the entire job_type table to satisfy the join — even when the
page only contains a handful of rows. That full-table hash scan is a roughly
fixed ~20 ms cost paid on every request to one of the busiest read endpoints in
the app.

job_group (~625 rows) and machine_platform (~256 rows, already resolved via a
Memoize'd index scan) are cheap; job_type is the one that hurts. Resolving the
reference data from the FK ids on the page instead keeps the cost proportional to
the page's distinct values (median ~27 per push) rather than the whole table.

Measured impact (server-side DB time, staging replica, per request)

Push size	master (3 joins)	this PR (lean + id__in)	delta
median (~20 types)	25.6 ms	1.3 ms	−24 ms (20×)
p90 (~250 types)	22.5 ms	2.2 ms	−20 ms (10×)
p99 (~2.5k types)	34.7 ms	14.8 ms	−20 ms (2×)
max (~13k types)	63.9 ms	30.7 ms	−33 ms (2×)

The win is largest on the common small pushes, because master pays the
full-job_type-table hash build regardless of page size. The cost added back is
three indexed id IN (...) fetches (in-cluster, ~1 ms total).

Correctness

The batch-fetch path was verified to produce byte-identical output to the
join-based path across the full push-size distribution (20 / 284 / 2000 / 2000
rows) on production-like data. Existing tests/webapp/api/test_jobs_api.py
coverage exercises both endpoints.

Scope / how to weigh this

This is intentionally marked Optional. It is complementary to — not a
substitute for — routing these endpoints to the read replica: that change
relocates the load off the primary, while this one reduces the cost of the query
wherever it runs. Once replica routing is in place, the primary no longer runs
these queries, so the remaining benefit here is replica CPU headroom under peak
poll QPS and a small per-poll latency improvement. Reasonable to defer if the
review/maintenance cost outweighs that.

Note: this is deliberately the join-removal-only approach. An alternative that
caches the full reference tables in Redis was prototyped and rejected — for
job_type it adds a ~5.8 MB per-request deserialize plus periodic full-table
rebuilds, which is a net regression on the small polling requests that dominate
traffic.