ci(pods): recover the missing ConvertSwiftSDK 2.0.0 pod — no version bump

[abbaseya]

The problem

v2.0.0 is published on every channel except one:

Channel	v2.0.0	Evidence
SPM (primary)	✅	tag v2.0.0 → b8b89b7
GitHub Release	✅	created 18:06:48, Latest
CocoaPods ConvertSwiftSDKCore	✅	Trunk: 1.0.0, 1.0.1, 2.0.0
CocoaPods ConvertSwiftSDK	❌	Trunk: 1.0.0, 1.0.1

Run 30115531359 failed at the last step only:

[!] Calling the GitHub commit API timed out. Please check GitHub's status and try again later.
##[error]Process completed with exit code 1.

Transient — not the token, not a version mismatch, not push ordering. Core had already published; the umbrella died in CocoaPods' podspec validation.

Why it can't be repaired with what's in the repo today

1. release.yml pushes core then the umbrella in one step under -e. Core 2.0.0 is now on Trunk, and Trunk rejects a duplicate name+version — so re-running the job aborts on the first push and never reaches the umbrella.
2. A push: tags: workflow runs the workflow file as it exists at the tag's commit. Fixing release.yml on main does nothing for a re-run of v2.0.0.

Manual pod trunk push isn't a clean path either: pod-name ownership sits with the account that first pushed, and repository secrets can't be read back out.

The fix — publish at 2.0.0, change no versions

A workflow_dispatch-only Publish Pod workflow that publishes one podspec from an existing tag:

• Checks out the tag, so the uploaded spec is byte-for-byte the one the release blessed — not whatever main holds later.
• Asserts the podspec's s.version equals the tag, reusing release.yml's exact grep/sed.
• Skips any version already on Trunk → idempotent, and immune to the duplicate-rejection trap that breaks the release-job re-run.
• Pushes with release.yml's exact flags — --synchronous for the umbrella only, since it alone declares s.dependency 'ConvertSwiftSDKCore', s.version.to_s.
• Confirms the version is live on Trunk (6 × 30s poll) so green means resolvable, not merely "exit 0".

No re-tagging. No version bump. No second GitHub Release. The podspecs are untouched — this PR contains zero changes to either .podspec.

Deliberately constrained

permissions: contents: read. It cannot create a Release, push a tag, or write to the repo, so it can never become a second release path. release.yml keeps its tag-only trigger and no workflow_dispatch — RELEASE.md safeguard #1 is about never releasing on a branch merge, which this doesn't do.

Verification

YAML parses; both shell paths exercised under bash (what Actions uses) against live Trunk data:

ConvertSwiftSDK      versions on Trunk: 1.0.0 1.0.1        -> ALREADY_PUBLISHED=false => PUSHES
ConvertSwiftSDKCore  versions on Trunk: 1.0.0 1.0.1 2.0.0  -> ALREADY_PUBLISHED=true  => SKIPS

Version assert against the tagged tree: both podspecs s.version=2.0.0 == tag 2.0.0 ✓

After merge

Actions → Publish Pod → Run workflow with tag: v2.0.0, podspec: ConvertSwiftSDK. (workflow_dispatch only becomes available once the file is on the default branch.)

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.