Make release creation an idempotent upsert instead of Get-then-Create

[Mpdreamz]

Follow-up to #32/#33 (Octokit's request serialization dropping fields under Native AOT). This one's on the read side.

What happened

Both assembly-rewriter and nupkg-validator got past release creation and label creation successfully this time (thanks to #32/#33), but then a concurrent CI run (a master push race, see context below) meant the release for that tag had already been created by the time the tag-triggered run got to this step. The pre-check that's supposed to catch that (client.Repository.Release.Get, deserializing Octokit's own Release model via the same unannotated reflection covered in #32/#33) silently failed too, so CreateRelease ran unconditionally and got:

Octokit.ApiValidationException: {"message":"Validation Failed","errors":[{"resource":"Release","code":"already_exists","field":"tag_name"}],"status":"422"}

Why not just fix the Get call

Given #32 and #33 already showed two unrelated models breaking two different (and non-obvious) ways under Octokit's zero-annotation reflection serializer, I don't trust patching around individual failures here to be the last one. The more robust shape is to stop needing a separate, fallible existence check at all.

Fix

GitHubReleaseClient.CreateOrUpdateRelease is now a self-contained upsert: always POST the release first. Only on a 422 already_exists does it resolve the existing release's id — via a minimal, source-generated-only GET returning just { id }, not Octokit's Release model — and PATCH it. ReleaseNotesRunner.CreateRelease no longer calls ReleaseExists at all before writing.

Verification

Simulated the full sequence (POST → 422 already_exists → GET id → PATCH) against a local HttpListener from a real native-AOT linux-x64 build:

POST releases RECEIVED: {"tag_name":"0.14.3","body":"hello body"}
GET /repos/o/r/releases/tags/0.14.3
Resolved release id: 424242
PATCH releases/id RECEIVED: {"body":"hello body"}
DONE

Made with Cursor