Drop [LATEST] rejection on authenticated generic downloads

[igalsi-t]

Context

`fly-service` PR (https://github.com/jfrog/fly-service/issues/1104 item 2) adds server-side `[LATEST]` resolution to the authenticated generic download endpoint:

• `GET|HEAD /fly/api/v1/generic/{package}/[LATEST]/{file}` → 302 to the most recently uploaded version on `{tenant}-generic-local`, with `Cache-Control: no-store`. The same `FindLatestGenericVersion` AQL helper resolves `[LATEST]` for the public download path, against `{tenant}-generic-public`.

Once the fly-service change is deployed to staging and production, the client-side rejection in `fly-action` (currently shipped on the `feature/generic-latest-support` branch) is obsolete and should be removed so consumers can use `[LATEST]` on authenticated downloads.

What to change

In the `feature/generic-latest-support` branch (or the merged equivalent on `main`):

• `src/transfer.ts` — remove the auth-side `[LATEST]` rejection.
• `lib/upload.js` and `lib/download.js` — remove or update any compiled paths that mirror the rejection.
• `download/action.yml` — update the `description` so the input documentation no longer says `[LATEST]` is public-only on this action.
• README sections "[LATEST] resolution" and "Authenticated" — update to describe the unified behaviour (one resolver, two repo tiers).

Test plan

• Build the action and exercise it end-to-end in a workflow against staging once fly-service ships.
• Confirm `fly-action/download` with `version: "[LATEST]"` follows the 302 and pulls the most recent uploaded version of the package.
• Confirm a download for a package with no uploaded version surfaces a clear 404 to the workflow.

Coordination

Open this PR after the fly-service change has shipped to production. Until then, the rejection prevents workflows from hitting an endpoint that 404s for `[LATEST]`.