[Advice] Can we remove jf cli install when our runner has pre-installed jf cli

Is your feature request related to a problem? Please describe.

Issued caused by this rate limit in GIthub EE runner:
Run jfrog/setup-jfrog-cli@v4
Setup JFrog CLI
Downloading JFrog CLI from https://releases.jfrog.io/artifactory/jfrog-cli/v2/[RELEASE]/jfrog-cli-linux-amd64/jfrog

16:29:13 [Warn] failed while trying to check latest JFrog CLI version: received HTTP status Forbidden from Github, there is no GitHub token, please set github token to avoid anonymous calls rate limits: {"message":"API rate limit exceeded for 35.82.120.215. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)","documentation_url":"https://docs.github.com/rest/overview/resources-in-the-rest-api#rate-limiting"}

16:29:13 [Info] Trace ID for JFrog Platform logs: 39ac14d06bdafb44

Error: 3 [Error] failed to exchange OIDC token: server response: 403 Forbidden
{
"errors": [
{
"code": "FORBIDDEN",
"message": "Forbidden"
}
]
}

Error: JFrog CLI exited with exit code 1

It seems that this issue happens in "Downloading JFrog CLI from https://releases.jfrog.io/artifactory/jfrog-cli/v2/[RELEASE]/jfrog-cli-linux-amd64/jfrog"

But since this Github runner is managed by ourself, and jf cli has been pre-installed after runner has been actived and work, so can we use some parameters to avoid installing jf cli in "jfrog/setup-jfrog-cli@v4" to solve this problem ?

If not, do you have some better solution to solve this issue ? (our Github is running with private enterprise version)

Describe the solution you'd like to see

use some parameters to avoid installing jf cli in "jfrog/setup-jfrog-cli@v4"

Describe alternatives you've considered

can we use jh login to solve this issue ?

Additional context

No response

Start by reviewing the setup-jfrog-cli@v4 action entry point and how it currently downloads JFrog CLI. Determine how a self-hosted runner's pre-installed CLI could be selected without the download step, then verify that a workflow can use the existing CLI without the reported rate-limit failure.