Accept an explicit tag on the reusable (workflow_call) path

[ilitteri]

Motivation

The reusable publish-apt.yml (workflow_call) only accepted a force input — there was no way for a caller to say which release to publish. With no tag, it always fell through to gh release view, which resolves GitHub's latest published, non-pre-release release. That lookup excludes pre-releases and lags a just-promoted release, so a caller that invokes this workflow at promotion time can resolve the previous version and publish the wrong .deb (or skip via the pool check), while the run stays green.

Description

• Add a tag input to the workflow_call signature (string, optional, default ""), mirroring the existing workflow_dispatch tag input.
• Resolve the tag from the inputs context (inputs.tag), which is populated for both the reusable and manual paths, instead of github.event.inputs.tag (manual only).
• Precedence is unchanged: an explicitly passed tag wins; with no tag it still falls back to the latest release, so existing behaviour is preserved.

This lets the ethrex release workflow pass the exact release it is promoting, so apt version resolution no longer depends on GitHub's eventually-consistent "latest release" lookup. Normalization already handles both 18.0.0 and v18.0.0 forms.

How to test

• Manual: Actions → Run workflow with tag=18.0.0 → builds/publishes 18.0.0.
• Reusable: a caller uses: this workflow with with: { tag: 18.0.0 } → publishes 18.0.0 regardless of what gh release view currently reports.
• No tag (manual or reusable): unchanged — falls back to the latest release.

[ElFantasma]

The change here is correct and the right root-cause fix (resolve from inputs.tag instead of the lagging gh release view). One coordination note, though: this is inert until the caller passes tag, and the caller currently doesn't.

ethrex#6920 is already merged, and its publish-apt job in .github/workflows/tag_latest.yaml calls this workflow without a with: block:

publish-apt:
  needs: [retag_docker_images]
  uses: lambdaclass/ethrex-apt/.github/workflows/publish-apt.yml@main
  secrets: { … }        # no `with: { tag: … }`

So after this PR merges, inputs.tag stays at its "" default → the workflow still falls through to gh release view → the exact lagging-"latest" race this PR is meant to remove. The apt half of the v18 breakage isn't closed yet.

Needs a follow-up in ethrex to actually pass the tag — the resolve job already exposes it:

publish-apt:
  needs: [resolve, retag_docker_images]
  uses: lambdaclass/ethrex-apt/.github/workflows/publish-apt.yml@main
  with:
    tag: ${{ needs.resolve.outputs.new_tag }}   # normalizes 18.0.0 / v18.0.0
  secrets: { … }

Merge order: this PR should land first; only then can the ethrex caller pass with: { tag: … } (since it pins @main, passing an input that doesn't exist yet would fail the call with "invalid input 'tag'").

Net: this PR is a correct prerequisite, but the apt path stays on the racy fallback until the ethrex publish-apt caller is updated to pass tag.