Retryable publishing via new `release_attached` output

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

It is not currently possible to retry steps that only run when the release_created output is true. It is true at most once per release.

That's great when on the happy path. But on the unhappy path, for example when publishing fails due to an expired secret or other transient error, there is no simple way to retry the publish step because release_created will never be true again.

      - name: Release Please
        id: release-please
        uses: actions/release-please-action@v4.4.0
      # THIS IS NOT RETRYABLE 👇 
      - name: Publish Asset
        if: steps.release-please.outputs.release_created
        run: pnpm asset:publish

Describe the solution you'd like

A new boolean output parameter called release_attached that is true both when the initial release is created, and when the action is run on a commit that already had a release attached to it. Looking at the logs for retried builds, release-please-action is already smart enough to know there was a previous release on the current git hash:

❯ Fetching releases with cursor undefined
❯ Found release for path ., v1.1.0-alpha.3
❯ release for path: ., version: 1.1.0-alpha.3, sha: 6b8ed5e613d8c6eba0d4f866b023bec8cbf94a74

Describe alternatives you've considered

I've considered manually writing my own script to detect whether the current commit has been released as a result of the current or a previous run. I'm really hoping to avoid that though, since the release-please-action seems to already have all the information needed.

Additional context

I realize that re-publishing can be a hazard. I'm not suggesting replacing release_created for simple use cases. I am asking for an additional output for power users who know how to build a safe, idempotent, retryable publishing mechanism.

Start by tracing the release-please-action output handling and the logic that finds a release attached to the current commit. Add the release_attached output for both newly created releases and existing attached releases, then verify that it is false when no release is attached and true in both requested cases.