Pinned version of `jfrog/setup-jfrog-cli@v4.5.6` breaks due to deleted artifact - violates SDLC stability expectations

Describe the bug

We are currently using a pinned version of the JFrog CLI GitHub Action:

uses: jfrog/setup-jfrog-cli@v4.5.6

We assume, as is standard in any well-defined Software Development Life Cycle (SDLC), that pinning a version means that version will remain stable and functional indefinitely.

However, this suddenly broke with the following error:

Error: 1 [Error] failed while adding JAS scan tasks: [Thread 2]  failed to download analyzer manager: 
couldn't get remote file details for https://releases.jfrog.io/artifactory/xsc-gen-exe-analyzer-manager-local/v1/1.13.2/linux-amd64/analyzerManager.zip: server response: 404

This appears to be due to a binary being deleted from your Artifactory repository.

This seems to have coincided with the recent release of jfrog-cli-security:

https://github.com/jfrog/jfrog-cli-security/releases/tag/v1.17.1

We rely on stable CI/CD tooling, and any breakage in that pipeline due to external instability is a serious problem.

Current behavior

A pinned version of a CLI tool should not break due to changes in remotely hosted artifacts.
Users should not be expected to upgrade the CLI every week to keep it from breaking.
Removing or invalidating a binary dependency without backward compatibility breaks production pipelines.

Reproduction steps

No response

Expected behavior

Pinned versions should be reliable and isolated from upstream removals.
Artifact deletions or moves must not affect existing stable versions.

Setup JFrog CLI version

4.5.6

JFrog CLI version

2.73.0

Workflow operating system type and version

Ubuntu 24.04.2 LTS

JFrog Artifactory version (if relevant)

No response

JFrog Xray version (if relevant)

No response

Start from the pinned jfrog/setup-jfrog-cli@v4.5.6 workflow entry and the reported analyzerManager.zip URL, then compare its failure with the jfrog-cli-security v1.17.1 release. Determine whether the deleted artifact and version interaction can be addressed within this action; the issue is done only when pinned versions no longer fail from unavailable remote artifacts or the supported stability behavior is documented.