`jf cargo publish`: checksum lookup AQL fails with 400 for non-admin users (`include` lacks `repo` and `path`)

Start in artifactory/commands/cargo/checksums.go at buildChecksumAql and compare its include fields with Artifactory's non-admin requirements. Verify the generated AQL includes repo, path, and name, then reproduce the lookup with a non-admin token and confirm cargo publish records the artifact checksums.

Describe the bug

After a successful cargo publish, jf cargo publish looks the checksums of the uploaded crate (and of
any dependency whose checksums the local cache did not provide) up with one AQL query, in
artifactory/commands/cargo/checksums.go, buildChecksumAql:

`items.find({"repo":%q,"$or":[%s]}).include("name","actual_sha1","sha256","actual_md5")`

The include clause names neither repo nor path. Artifactory rejects such a query for every
non-admin user with HTTP 400, because it needs repo, path and name in the result to evaluate the
caller's permissions per item. The enrichment is best-effort, so the command still exits 0, but the
published crate lands in the build-info without any checksum, and dependency checksums that were
missing locally stay missing.

Only an admin token gets checksums. A CI identity with read and deploy on the repository, which is the
normal case, never does.

Current behavior

With a non-admin access token (the identity has read/deploy on the local repository and read on the
remote):

Uploaded cargo-sample v1.0.7 to registry `playground-cargo-private-testing-onprem-local`
Published cargo-sample v1.0.7 at registry `playground-cargo-private-testing-onprem-local`
10:52:00 [Warn] cargo: checksum enrichment failed: checksum enrichment incomplete (filled 0 before error): server response: 400 Bad Request
{
  "errors" : [ {
    "status" : 400,
    "message" : "For permissions reasons AQL items domain demands the following fields: repo, path and name."
  } ]
}
10:52:00 [Warn] cargo: published crate cargo-sample-1.0.7.crate not found in repo playground-cargo-private-testing-onprem-local yet; checksums omitted
10:52:00 [Info] Setting properties...
10:52:00 [Info] Done setting properties.
10:52:00 [Info] cargo: set build properties on 1 artifacts (batch)
10:52:00 [Info] cargo build info saved locally

The crate is in the repository and carries the build.name/build.number properties, but the module in
the published build-info reads:

{
  "id": "cargo-sample:1.0.7",
  "type": "cargo",
  "artifacts": [
    { "name": "cargo-sample-1.0.7.crate", "type": "crate", "path": "crates/cargo-sample/cargo-sample-1.0.7.crate" }
  ]
}

No sha1, sha256 or md5 on the artifact. The same happens on a JFrog SaaS instance with an
OIDC-minted token (GitHub Actions), and on a self-hosted 7.161.20 with a plain access token.

Reproduction steps

The AQL itself reproduces it without cargo. With a non-admin server configuration (jf c add with an
access token of a user that is not an admin) and any crate already in a Cargo local repository:

# What `jf cargo publish` sends: rejected for a non-admin user.
jf rt curl -XPOST /api/search/aql -H 'Content-Type: text/plain' -d \
  'items.find({"repo":"<cargo-local>","$or":[{"name":"<crate>-<version>.crate"}]}).include("name","actual_sha1","sha256","actual_md5")'
# -> 400 "For permissions reasons AQL items domain demands the following fields: repo, path and name."

# The same query with the three mandatory fields: accepted for the same user.
jf rt curl -XPOST /api/search/aql -H 'Content-Type: text/plain' -d \
  'items.find({"repo":"<cargo-local>","$or":[{"name":"<crate>-<version>.crate"}]}).include("repo","path","name","actual_sha1","sha256","actual_md5")'
# -> 200, one result with actual_sha1 / sha256 / actual_md5

End to end, with the same non-admin server configuration:

cargo new --lib probe && cd probe
cat >> ~/.cargo/config.toml <<EOF
[registries.<cargo-local>]
index = "sparse+https://<host>/artifactory/api/cargo/<cargo-local>/index/"
EOF
jf cargo publish --registry <cargo-local> --build-name probe --build-number 1
# -> the two [Warn] lines above; the crate is uploaded, the build-info artifact has no checksums.

Running the same with an admin token yields no warning and a fully checksummed artifact, which is how
the gap hides in local testing.

Expected behavior

The lookup works for any user who may read the repository, i.e. buildChecksumAql includes the three
fields Artifactory requires:

.include("repo","path","name","actual_sha1","sha256","actual_md5")

parseChecksumResults already keys the results by name, so the extra fields change nothing else.

JFrog CLI-Core version

v2.60.1-0.20260831061529-c6dd293bccca (as bundled in JFrog CLI 2.124.0)

JFrog CLI-Artifactory version

v0.8.1-0.20260902124259-4c1979144d2f (as bundled in JFrog CLI 2.124.0; buildChecksumAql on main is unchanged)

JFrog CLI version (if applicable)

2.124.0

Operating system type and version

Linux x86_64 (GitHub-hosted ubuntu-latest runner, and a Debian-based container image)

JFrog Artifactory version

7.161.20 (self-hosted) and JFrog SaaS