1. 1. Summary

`buildscripts/tests/burn_in/test_bazel_burn_in_end2end.py` is by far the longest test in the `buildscripts_test` suite (~168s historical average, more than half the suite's total runtime). Its `setUpClass` ran a `bazel build` followed by a `bazel cquery` to map each `resmoke_config` target to its generated config file.

The `cquery` constructs its own configured-target graph, so it cost *more than the build it followed*.

1. 1. Bottom line

Measured locally, first run of each step on the same tree:

The 27.9s was a first `cquery` on a Bazel server that had already completed the build, so nearly all of it was the second analysis pass — over ~41k configured targets — that this PR removes outright. Targets built drops 567 -> 406.

This matters because the task's idle timeout is derived as 3x the slowest test's historical average, which worked out to 9 minutes and was tripped in BF-45324 when a cold Bazel analysis cache pushed this test past it.

1. 1. Changes

• `_bazel_query_command()` replaces `_bazel_cquery_command()` — a plain `bazel query`, loading phase only, no `--output=starlark` expression.
• `_resmoke_config_output_path()` derives the config path from the label. `_resmoke_config_impl` in `bazel/resmoke/resmoke.bzl` declares its output as `<target name minus the _config suffix>.yml` in the target's own package, so the path is fully determined by the label.
• `_resmoke_suite_configs()` builds the `label -> path` mapping and filters targets that produce no config file with `os.path.exists`, preserving the behavior of the `if target.files.to_list() else ''` guard from SERVER-131300.
• `_bazel_build_command()` scoped from `//...` to `//jstests/suites/...`, matching what the query consumes.
• Renamed `_run_bazel_cquery_with_backoff` -> `_run_bazel_query_with_backoff` and the two unit tests that reference it.

1. 1. Safety / compatibility

• *Output is unchanged.* Verified the generated `resmoke_suite_configs.yml` against a baseline captured from the old code on the same tree: 406 of 406 entries, identical label set, and every path resolving to the same file on disk.
• The only textual difference is `bazel-bin/...` vs `bazel-out/aarch64-fastbuild/bin/...`. Both resolve identically, and the previous code already depended on the sibling `bazel-out` convenience symlink, so this is not new exposure.
• Retry/backoff behavior around the Bazel invocations is unchanged.

1. 1. Testing

• `TestBazelCommandConfiguration`, `TestRunBazelCommandWithBackoff`, `TestListComprehensionRuleParser` — 6 tests pass.
• Output equivalence verified as described above.
• The full `TestBazelBurnInEnd2End` class has not been run locally; leaving that to a patch build.