admission: audit resource group id plumbing

**Describe the problem**

**Summary:**

1. Audit remaining `WorkInfo` construction sites

There are other places that construct or copy `admission.WorkInfo`. Make sure we are not silently dropping `ResourceGroupID`. For at least some of those sites the value may not matter — if the path never reaches the CTT (cost-tracking/throttling) admit path, the missing id should be . We should:

- [ ] Grep for all `admission.WorkInfo{...}` literals and `WorkInfo` copies across `pkg/sql`, `pkg/kv`, and adjacent packages.
- [ ] For each site, determine whether the work can reach the CTT admit path. Plumb `ResourceGroupID` through.
- [ ] Consider whether a constructor / copy helper on `WorkInfo` would make future leak sites less likely (e.g. a `WorkInfoFromHeader` that copies all admission-relevant fields).

2. Assigning jobs (and LDR) to resource groups

Today, job-driven work generally does not set a `ResourceGroupID`. Jobs typically run at `admissionpb.LowPriority`. On the **KV** side this is mostly fine - low priority routes into the elastic CPU admission queue regardless of resource group. On the **SQL** side, however, we still need to classify work into a resource group to apply operator-configured CPU weights, and priority alone is not sufficient.

Options worth thinking through (this needs UX input):

- A built-in "jobs" / per-priority resource group that low-priority background work is automatically routed to, so operators can shape it as a single bucket.
- A way to assign jobs (or specific job types - LDR, changefeeds, backups, schema changes, …) to operator-named resource groups, analogous to `SET resource_group` for sessions. Probably a per-job setting and/or a cluster-level default per job type.
- Some combination — a default jobs group with an override per job type or per job instance.

Jira issue: CRDB-64627