Manual numbered prerelease falsely rejects newer target from shallow checkout

[Exohayvan]

Bug description

A manually promoted numbered prerelease fails during the final publish job even when the selected target commit is newer than the latest published prerelease.

The failed job also creates an entry under Deployments with environment release, while no new entry appears under Releases.

Reproduction

Workflow: Desktop Build and Numbered Prerelease

1. Run the workflow manually from main.
2. Use release_ref: main and enable publish_release.
3. The workflow resolves target SHA ea21c3c3626cab80f15cbc3d747a05aa177f33a6.
4. All four desktop build jobs pass.
5. Publish manually promoted prerelease fails in Re-check sequence and publish with:

target is not newer than v0.2.0-alpha.118

Observed run: https://github.com/AetherMesh-AI/aethermesh-core/actions/runs/29970384473

Evidence

• Latest published prerelease: v0.2.0-alpha.118 at cac87db53ed501453b48c9027bacc6decbb943a8
• Requested target: ea21c3c3626cab80f15cbc3d747a05aa177f33a6
• In a complete repository clone, this succeeds:

git merge-base --is-ancestor v0.2.0-alpha.118 ea21c3c3626cab80f15cbc3d747a05aa177f33a6

Therefore the target really is a descendant of .118 and contains newer commits.

Suspected root cause

Both publication jobs check out the target with the default shallow depth:

- uses: actions/checkout@v4
  with:
    ref: ${{ needs.resolve.outputs.target_sha }}

The composite action fetches origin main and the numbered tags, but it does not explicitly deepen or unshallow the checkout before running:

git merge-base --is-ancestor "$previous_tag" "$TARGET_SHA"

The shallow boundary can make Git report false for a valid ancestor relationship, causing the misleading target is not newer failure.

Why it appears under Deployments

The manual publish job declares:

environment: release

GitHub Actions automatically creates a deployment record for jobs that reference an environment. In this run, the job failed before reaching gh release create, so GitHub recorded a failed release deployment but did not create v0.2.0-alpha.119 under Releases.

Expected behavior

• A manually promoted target newer than .118 publishes the next immutable prerelease, .119, with all four validated desktop artifacts and source metadata.
• The ancestry check operates on sufficient Git history and does not reject a valid descendant.
• The workflow's use of the release environment is intentional and clearly distinguished from a GitHub Release. If a Deployment entry is not desired, the workflow should preserve any required approval/security behavior without creating misleading deployment records.

Acceptance criteria

• Add a regression check that reproduces ancestry validation from a shallow Actions checkout.
• Ensure both manual and scheduled publication jobs have enough history for merge-base and rev-list checks.
• Verify a manual publish from a newer main commit creates exactly the next numbered prerelease and does not move an existing tag.
• Verify a target with no commits after the latest prerelease is still rejected in manual mode and skipped in scheduled mode.
• Decide whether environment: release should remain. If it remains, document that it creates Deployment records and confirm failed publication does not imply a GitHub Release was created.