`enable-package-alias: true` installs the alias but never activates it (`JFROG_CLI_GHOST_FROG` is never set)

Describe the bug

With enable-package-alias: true, the action runs jf package-alias install and appends the alias directory to GITHUB_PATH, but it never sets the JFROG_CLI_GHOST_FROG environment variable. JFrog CLI's package-alias ("Ghost Frog") interception is opt-in and off by default — DispatchIfAlias returns early unless JFROG_CLI_GHOST_FROG is set. So the documented behavior ("mvn, npm, go, etc. are transparently intercepted in subsequent steps") never happens: the go shim is on PATH, but with the gate off, go mod download runs the jf binary as a normal CLI (jf mod download) and fails.

This is independent of JFrog platform/auth configuration — it fails before any network call, purely because the interception gate is off.

Current behavior

In a step after the action:

• jf package-alias status reports State: ENABLED, PATH: Configured [OK], and Package aliasing is active. You can now run: ... go build — i.e. it looks active.
• echo "$JFROG_CLI_GHOST_FROG" → empty (the action never exported it).
• go mod download →

  'jf mod' is not a jf command. See --help
  ##[error]Process completed with exit code 1.
  

Reproduction steps

Minimal workflow — no JFrog instance or secrets required:

- uses: actions/setup-go@v6
  with: { go-version: "1.23" }
- uses: jfrog/setup-jfrog-cli@v5.1.0
  with:
    version: 2.111.0
    enable-package-alias: true
- run: jf package-alias status   # reports "active"
- run: go mod download           # 'jf mod' is not a jf command -> exit 1

Runnable, green-CI proofs (matrix over jf 2.100.0 / 2.111.0 / latest): https://github.com/wberry-godaddy/jfrog-cli-examples — see the 05-setup-action-gap workflow.

Expected behavior

With enable-package-alias: true, subsequent go/npm/… commands should actually be intercepted, as documented. The action should export JFROG_CLI_GHOST_FROG to GITHUB_ENV — the env-var counterpart to the GITHUB_PATH it already appends.

Suggested fix / consideration: exporting JFROG_CLI_GHOST_FROG=true activates interception for every go/npm/mvn call in later steps, which can break steps running commands that aren't backed by a configured resolver. Consider gating it behind an explicit input (e.g. package-alias-mode: true|audit|off) rather than enabling it unconditionally.

Secondary: the minimum-version gate for this feature is 2.93.0 (MIN_CLI_VERSION_PACKAGE_ALIAS), but jf package-alias first ships in JFrog CLI 2.100.0 (jfrog/jfrog-cli#3375). With version pinned to 2.93.0–2.99.x, jf package-alias install fails and the action only logs a warning, so the floor likely should be 2.100.0.

Versions

• Setup JFrog CLI version: v5.1.0
• JFrog CLI version: reproduced on 2.100.0, 2.111.0, and latest
• Workflow operating system type and version: ubuntu-latest (GitHub-hosted)
• JFrog Artifactory version: n/a (not needed to reproduce)
• JFrog Xray version: n/a

Trace the enable-package-alias input handling and the existing GITHUB_PATH update in the action, then inspect how later steps receive environment variables. Reproduce the provided workflow without JFrog credentials, decide how activation should be gated, and verify that package-alias commands such as go mod download are intercepted while the minimum CLI version is handled correctly.