batch: reduce server overhead when dispatching jobs from CLI

[tgross]

When dispatching parameterized jobs or forcing periodic jobs to run via the CLI, we do a prefix lookup as we do with most other commands. But in this case we end up getting a potentially very large set of jobs back from the server, even if we have an exact match for the prefix. This can cause excess CPU/memory load in the RPC and HTTP API handlers as we have to serialize these large sets just to report the error to the user.

Update the CLI so that it uses a go-bexpr filter to filter down to the set of jobs we need for these operations. This requires an update to go-bexpr to support nil checking on pointers in structs. Also add a page size to the list results to reduce the load for all commands that need to do a prefix lookup on jobs.

Ref: https://hashicorp.atlassian.net/browse/NMD-941
Ref: hashicorp/go-bexpr#129
Fixes: #26653

Testing & Reproduction steps

$ nomad job run ./jobs/mini-dispatch.nomad.hcl
Job registration successful

$ nomad job dispatch -detach ex
Dispatched Job ID = example/dispatch-1772727387-5152f356
Evaluation ID     = e89062dc

$ nomad job dispatch -detach example/dispatch
No parameterized job(s) with prefix or ID "example/dispatch" found

$ nomad job run ./jobs/periodic.nomad.hcl
Job registration successful
Approximate next launch time: 2026-03-05T21:30:00-08:00 (13h12m42s from now)

$ nomad job periodic force myperiodic
==> 2026-03-05T11:17:30-05:00: Monitoring evaluation "57e5796f"
    2026-03-05T11:17:30-05:00: Evaluation triggered by job "myperiodic/periodic-1772727450"
    2026-03-05T11:17:31-05:00: Allocation "ebbb6ef4" created: node "fd15cdd9", group "group"
    2026-03-05T11:17:31-05:00: Evaluation status changed: "pending" -> "complete"
==> 2026-03-05T11:17:31-05:00: Evaluation "57e5796f" finished with status "complete"

$ nomad job periodic force example
No periodic job(s) with prefix or ID "example" found

Contributor Checklist

• Changelog Entry If this PR changes user-facing behavior, please generate and add a
  changelog entry using the make cl command.
• Testing Please add tests to cover any new functionality or to demonstrate bug fixes and
  ensure regressions will be caught.
• Documentation If the change impacts user-facing functionality such as the CLI, API, UI,
  and job configuration, please update the Nomad product documentation, which is stored in the
  web-unified-docs repo. Refer to the web-unified-docs contributor guide for docs guidelines.
  Please also consider whether the change requires notes within the upgrade
  guide. If you would like help with the docs, tag the nomad-docs team in this PR.

Reviewer Checklist

• Backport Labels Please add the correct backport labels as described by the internal
  backporting document.
• Commit Type Ensure the correct merge method is selected which should be "squash and merge"
  in the majority of situations. The main exceptions are long-lived feature branches or merges where
  history should be preserved.
• Enterprise PRs If this is an enterprise only PR, please add any required changelog entry
  within the public repository.

• If a change needs to be reverted, we will roll out an update to the code within 7 days.

Changes to Security Controls

Are there any changes to security controls (access controls, encryption, logging) in this pull request? If so, explain.

[allisonlarson]

Neat!! I have one clarifying question for my understanding, but otherwise 👍

[allisonlarson]

I poked around and saw that JobListStub.ParameterizedJob is a bool; are there cases where the value would be false instead of nil? Or does it always get serialized as nil if the actual ParameterizedJobConfig isn't present on the Job?

[tgross]

I got caught by this too when I was working on it, because it's a little surprising: the filter expression is not on the stub but on the full object. Ref https://developer.hashicorp.com/nomad/api-docs#list-stubs

Some list endpoints return a reduced version of the resource being queried. This smaller version is called a stub and may have different fields than the full resource definition. To allow more expressive filtering operations, the filter is applied to the full version, not the stub.

This is a particularly weird case because we have a field with the same name that's of a different type!

[allisonlarson]

Oh wow! There it is 😅 Yeah, just poking through the code didn't make that clear at all. Thanks!! This makes a lot more sense, and makes the filtering way more powerful here than I thought