fix(release): restore v1.0.0 tag reachability + stop monorepo-builder from creating release commits

[abbaseya]

Summary

The release pipeline has been broken since the 2026-04-27 first-release run. The PR #37 merge yesterday surfaced it (Release workflow failed with Provided version "1.0.0" must be greater than the last one: "1.0.0"). This PR fixes both the immediate breakage and the underlying architectural defect that caused it.

Root cause

Two release tools were racing:

• @semantic-release/git (intended owner of commit + tag + push) computes the next version from v* tags reachable from main.
• symplify/monorepo-builder release "<version>" (chained into release.config.mjs:37 as part of the prepare step) also creates its own commit + tag + push, and its ReleaseGuard checks against all tags in the repo (git tag -l), regardless of reachability.

On 2026-04-27, monorepo-builder won the race: it pushed the 1.0.0 tag pointing at a "prepare release" commit (bf6f62a) that was never merged into main. @semantic-release/git then added the matching v1.0.0 tag pointing at the same orphan commit. Result: v1.0.0 exists on origin but is invisible to semantic-release because it is not in main's ancestry. Every subsequent release run defaults to first-release 1.0.0 and is rejected by monorepo-builder's guard.

What this PR does

Change 1 — release.config.mjs: drop the chained monorepo-builder release "<version>" call. Keep only bump-interdependency. @semantic-release/git becomes the sole owner of commit + tag + push, and (unlike monorepo-builder) it pushes the commit to main, not just the tag — so future release commits stay reachable.

Change 2 — merge v1.0.0 into the branch: brings the orphan bf6f62a into main's ancestry via a real merge commit. The v1.0.0 tag is not moved, not deleted — it keeps pointing at bf6f62a. After this PR lands, git merge-base --is-ancestor v1.0.0 main succeeds.

Expected behavior after merge

The Release workflow fires once on this PR's merge to main. semantic-release sees v1.0.0 reachable, computes next version off the fix: commits since then (PR #37's fix(context): + this PR's fix(release):), and @semantic-release/git publishes v1.0.1 on a commit that lives on main. Packagist gets notified, and release #3 onward will follow the same clean path.

⚠️ MERGE STRATEGY

Must be merged with "Create a merge commit" (not Squash, not Rebase). Squash or rebase would replay the commits as new ones and the orphan bf6f62a would never land in main's ancestry — v1.0.0 would stay invisible and the same bug would persist.

Test plan

• Confirm Quality Checks pass on this PR
• Merge via "Create a merge commit"
• Verify git fetch origin && git merge-base --is-ancestor v1.0.0 origin/main exits 0
• Watch the triggered Release workflow run; expect tag v1.0.1 created on a commit that is an ancestor of main
• Verify Packagist publishes convertcom/php-sdk 1.0.1

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request migrates the release process to semantic-release and adjusts the monorepo-builder configuration to prevent race conditions during the prepare phase. It also updates inter-package dependency constraints to caret ranges and reformats several composer.json files. The reviewer identified a critical architectural issue where relative paths are used in the autoload section of the Data and Experience packages, which would break functionality when these packages are installed as standalone dependencies. Additionally, the reviewer recommended removing the redundant version field from all composer.json files to prevent metadata staleness now that the automated bumping tool has been removed from the release process.