Feature/xray 138688 add yarn support for jf ca

[gauriy-tech]

• The pull request is targeting the dev branch.
• The code has been validated to compile successfully by running go vet ./....
• The code has been formatted properly using go fmt ./....
• All static analysis checks passed.
• All tests have passed. If this feature is not already covered by the tests, new tests have been added.
• Updated the Contributing page / ReadMe page / CI Workflow files if needed.
• All changes are detailed at the description. if not already covered at JFrog Documentation, new documentation have been added.

---

Add Yarn V2/V3 support for jf curation-audit

Previously jf ca had no Yarn support — running it on a Yarn project would either silently resolve via the npm code path or produce incomplete results. This PR adds full Yarn Berry (V2/V3) support.

What changed:

Curation install via Artifactory — rewrites the Yarn registry URL in .yarnrc.yml to the api/curation/audit// endpoint before running yarn install --mode=update-lockfile, then restores the original config. This routes all Yarn resolution through the curation service so 403 responses surface blocked packages.

Blocked package detection when install fails — when a curation 403 aborts the lockfile write (Yarn V3 rolls back on any error), the code falls back to probing declared direct dependencies via HEAD requests and renders the same blocked-package table the normal path produces.

Workspace member support — jf ca --working-dirs= on a Yarn workspace member re-routes to the workspace root automatically (Yarn V2+ cannot operate from a non-root). A new DetectedTechnologiesListForCurationAudit() promotes npm-detected workspace members to Yarn so the correct code path runs.

Workspace member filtering in graph — local workspace member packages (identified by the Yarn Berry name-hash pattern, e.g. admin-ui-428bae:0.0.0) are skipped when probing Artifactory — they have no remote artifact.

Root-only dep scope — when jf ca is run from a workspace root without --working-dirs, only the root package.json direct deps are audited. Use --working-dirs to audit individual members.

--run-native guard — --run-native is explicitly rejected for non-npm techs with a clear error; only npm implements the matching native-config flow today.

Graceful non-JSON 403 handling — when Artifactory returns an HTML error page instead of a JSON curation envelope, the package is still recorded as blocked with unknown policy rather than being silently dropped.

Testing done is documented here
https://jfrog-int.atlassian.net/browse/XRAY-140292

[gauriy-tech]

I have read the CLA Document and I hereby sign the CLA

[gineshkumar]

Two new code paths in this PR handle the same upstream condition (a 403 with an unparseable or empty-Errors body) but produce very different report rows:

• yarn V2 probe (yarn.go:857,911): row shows "Blocked by curation (response could not be parsed)" — honest.
• General walker (curationaudit.go:1098,1109): row shows Policy violations with empty Policy / Explanation / Recommendation — looks identical to a real policy block.

The general walker runs for every tech (npm, pip, maven, gradle, yarn-V3-success-path, …), so the silent-collapse behaviour is the dominant case across the product. A support engineer triaging a later ticket has no way to tell "real policy block, empty payload" from "403 we couldn't decode."

Worth aligning the two paths before merge.

[gauriy-tech]

Two new code paths in this PR handle the same upstream condition (a 403 with an unparseable or empty-Errors body) but produce very different report rows:

• yarn V2 probe (yarn.go:857,911): row shows "Blocked by curation (response could not be parsed)" — honest.
• General walker (curationaudit.go:1098,1109): row shows Policy violations with empty Policy / Explanation / Recommendation — looks identical to a real policy block.

The general walker runs for every tech (npm, pip, maven, gradle, yarn-V3-success-path, …), so the silent-collapse behaviour is the dominant case across the product. A support engineer triaging a later ticket has no way to tell "real policy block, empty payload" from "403 we couldn't decode."

Worth aligning the two paths before merge.

[gauriy-tech]

#759 (comment)

Fixed. Added a guard after extractPoliciesFromMsg: when blockingReason == BlockingReasonPolicy but len(policies) == 0 (regex found no {policy,...} groups), we now fall back to BlockingReasonUnknown. All three unparseable-403 paths in getBlockedPackageDetails now consistently produce "Blocked by curation (response could not be parsed)", matching the yarn V2 probe path.