fix(release): handle empty manifest for first release auto-merge

[fiunchinho]

Summary

The auto-merge reconcile step in .github/workflows/release.yaml mis-classifies the bump on a brand-new repo's first release-please PR, leaving auto-merge disabled even when the configured auto-merge-level would allow it.

Reproduction

On a fresh repo (manifest is {} until the first release lands), the run logs show:

Release PR #2: null -> 1.0.0 (none bump); auto-merge-level=minor
Auto-merge already in desired state (enabled=false, want=false); nothing to do

null -> 1.0.0 and bump=none are wrong — there's a real version on the PR head branch.

Root cause

manifest_version() runs jq -r '.["."]' against the manifest. On the base branch the manifest is {}, so jq returns the string null. The subsequent IFS=. read -r cmaj cmin cpat <<<"$current" produces cmaj=null, and the -gt arithmetic comparisons all silently evaluate to false (bash treats unset/non-numeric as 0 in this context under set -e), so the chain falls through to bump=none. Auto-merge is then never enabled, since none is below every auto-merge-level.

Fix

Normalize a missing "." key to "0.0.0" in manifest_version() using jq's alternative operator:

-              -H "Accept: application/vnd.github.raw" | jq -r '.["."]'
+              -H "Accept: application/vnd.github.raw" | jq -r '.["."] // "0.0.0"'

With the fix, the same first-release scenario classifies correctly as 0.0.0 -> 1.0.0 (major bump). Whether the PR actually auto-merges then depends on auto-merge-level as documented — a major bump still won't merge at level minor, which is the intended behavior.

Test plan

• Inspected diff is the single-line jq change plus an explanatory comment.
• Tested against giantswarm/test-release-please (a fresh repo with an empty manifest) by pinning its workflow to this branch — will report the run output here once the PR is open and the test workflow is updated.