fix: use gh API for tag creation and switch to USER_MANAGED publishing

[jakubuid]

Summary

• Fix tag push 403 error: Create git tags via gh api with PUSH_GITHUB_TOKEN instead of git push which fails because the default GITHUB_TOKEN has read-only Contents permission
• Merge tag + release steps into one since they share the same GH_TOKEN
• Switch publishing_type from automatic to USER_MANAGED so artifacts can be reviewed and published manually from the Central Portal dashboard (automatic wasn't reliably publishing)
• Remove waitForArtifactsToBeAvailable polling loop since it's not needed with user-managed publishing

Fixes: https://github.com/reown-com/reown-kotlin/actions/runs/22137041542/job/63991318247

Test plan

• Merge to develop, then to master to trigger the release workflow
• Verify git tag is created successfully via gh API
• Verify GitHub Release is created
• Verify artifacts appear in Central Portal dashboard for manual publishing

🤖 Generated with Claude Code

[claude]

Claude finished @jakubuid's task in 1m 41s —— View job

---

PR Review

• Read changed files
• Analyze workflow security
• Run breaking changes subagent
• Post review

---

No breaking changes found. One issue to flag:

Found 1 issue(s)

Issue 1: gh release create not guarded by tag-exists check — will fail if tag already exists

ID: ci-release-duplicate-release-a3f1
File: .github/workflows/ci_release_artifacts.yml:111
Severity: MEDIUM
Category: code_quality

Context:

• Pattern: The tag-creation block checks whether the tag already exists and skips if so, but gh release create runs unconditionally immediately after. If the tag exists (e.g. workflow re-run), the release creation will fail with "Release already exists."
• Risk: A workflow re-run after a partial failure (tag created, release failed for other reasons) will always error at the release step even though the intent is idempotency.
• Trigger: Any re-run of the workflow after the tag was successfully pushed but the release step failed for an unrelated reason.

Recommendation: Mirror the idempotency guard for the release step:

if gh release view "$TAG" >/dev/null 2>&1; then
  echo "Release $TAG already exists, skipping"
else
  gh release create "$TAG" \
    --target master \
    --title "$TAG" \
    --generate-notes
fi

Fix this →

Other observations (non-blocking):

• Merging the tag + release steps into one is cleaner — the original split was inconsistent since GH_TOKEN was only on the release step anyway.
• USER_MANAGED is the correct choice here; automatic can silently fail if validation errors occur before promotion.
• Removing waitForArtifactsToBeAvailable is correct — that polling loop was only needed with automatic publishing.
• No workflow security issues (no pull_request_target usage).

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud