bulkingest: investigate whether foreground workload is sufficient for admission control throttling

**Summary**

Follow-up to #165339. PR #165813 fixed the bulkingest roachtest's `elastic=false` variant to also disable the SST batcher's elastic control (`bulkio.ingest.sst_batcher_elastic_control.enabled`), but we are still seeing roughly the same throughput as before — the `elastic=false` variant does not outperform the default.

This suggests that elastic CPU control may not be the primary bottleneck, or that admission control is not actively throttling in this workload configuration.

**Investigation areas**

- **Foreground workload volume:** Check whether the bulkingest test generates enough foreground traffic for admission control to engage and actually throttle the elastic/background work. If foreground load is negligible, admission control may not be doing any meaningful pacing regardless of the elastic settings.
- **CPU utilization characteristics:** Examine CPU metrics from the Grafana dashboard during a run. If CPUs are not saturated, elastic throttling would have no effect and disabling it wouldn't change throughput.
- **Admission control metrics:** Look at admission control dashboard panels to confirm whether elastic work is actually being throttled during default runs.

**Next steps**

- [ ] Measure foreground traffic volume during a bulkingest run
- [ ] Review CPU utilization from Grafana dashboards during both `elastic=true` and `elastic=false` runs
- [ ] Check admission control metrics to confirm whether throttling is occurring

Jira issue: CRDB-62229

Epic CRDB-65516