chore(release): bump podspecs to 2.0.0

[abbaseya]

Step 1 of the two-step release in RELEASE.md: bump s.version in both podspecs on main, then push the v2.0.0 tag at the merge commit.

What this changes

File	From	To
ConvertSwiftSDKCore.podspec	1.0.1	2.0.0
ConvertSwiftSDK.podspec	1.0.1	2.0.0

Both must carry the same value — ConvertSwiftSDK declares s.dependency 'ConvertSwiftSDKCore', s.version.to_s. The release workflow's "Assert podspec versions match tag" step fails the release if either drifts from the tag, so this PR has to land before the tag is pushed.

Why 2.0.0 (major)

RELEASE.md → Version Numbering: fix: → patch, feat: → minor, breaking → major. The version is chosen by the maintainer and encoded in the tag; nothing computes it.

Commit 844c347 in the 43 commits since v1.0.1 is the only breaking one:

feat!: anchored bucketing layout for traffic ramping (contract v12)

BREAKING CHANGE: bumps the cross-SDK bucketing contract to v12. Experiences
served with `version` greater than 11 are bucketed with the anchored layout,

This matches the Android SDK, which released v2.0.0 from the equivalent feat(bucketing)!: add anchored bucketing layout for ramping allocations.

Verification (local, on this branch)

• swift build — Build complete
• swift test — 387 tests in 81 suites passed
• swiftlint lint --strict — 0 violations, 0 serious in 182 files

Next step after merge — not automatic

The iOS SDK has no release-on-merge: release.yml triggers exclusively on on: push: tags: 'v[0-9]+.[0-9]+.[0-9]+', with no branches: key and no workflow_dispatch. Merging this PR publishes nothing. A maintainer then runs:

git switch main && git pull origin main
git tag v2.0.0 && git push origin v2.0.0

That tag push is what fires the Release workflow → SPM (the tag itself) + GitHub Release + both pods to CocoaPods Trunk.

[gemini-code-assist]

Caution

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