ci: keep uv.lock in sync on the release-please branch

[kartojal]

Every release-please merge bumps the version in pyproject.toml but leaves uv.lock recording the previous one, so uv sync --locked fails Static Checks on main until someone regenerates the lockfile by hand (done manually after 0.1.0, 0.2.0 (#207), and 0.3.0). It bit again while this PR was open: 0.4.0 merged with a stale lock, which is failing CI on main right now and broke the 0.4.0 API reference upload. This PR carries that lock sync too (regenerated with current uv, which also normalizes some sphinx markers written by an older uv), so merging it heals main.

Fix: a sync-lockfile job runs after release-please, checks out the release PR branch, runs uv lock, and commits the result, so the release PR merges self-contained. A workflow step instead of release-please extra-files because uv lock rewrites the lockfile wholesale (an x-release-please-version annotation would not survive) and the toml updater would need a fragile jsonpath into the [[package]] array. The commit step no-ops when the lock is already current, and publish does not depend on this job, so a sync failure can never block a publish.

Release-please also writes semver-style prerelease versions (0.3.0-b2) into pyproject.toml, and the __version__ fallback in src/polymarket/version.py is not updated at all, which is the other half of the recurring release: canonicalize python beta version commits. Worth its own ticket rather than bundling it here.

Closes DEV-483

---

Note

Low Risk
CI-only changes with scoped contents: write on the release branch; publish is intentionally decoupled from lockfile sync.

Overview
Automates uv.lock updates on release PRs so version bumps from release-please no longer leave main failing uv sync --locked until someone regenerates the lockfile manually.

The Release Please workflow now uses a concurrency group, exposes prs_created from the release step, and adds a sync-lockfile job that runs when a release PR is created. That job checks out the release-please--branches--main--components--polymarket-client branch, runs uv lock, and commits/pushes only if uv.lock changed. publish still depends only on release-please, so a sync failure cannot block PyPI publish.

The uv.lock diff reflects the intended outcome: workspace package version 0.3.0 → 0.4.0 plus lockfile normalization (e.g. Sphinx dependency markers) from a full uv lock rewrite.

^{Reviewed by Cursor Bugbot for commit e113750. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit e113750. Configure here.}

[cursor]

Lock sync skipped after PR updates

High Severity

The sync-lockfile job only runs when prs_created is true, but that output stays false when release-please updates an existing release PR. Those updates rebuild the branch from main and drop any prior uv.lock sync commit, so the lockfile drifts again before merge and uv sync --locked fails on main.

 

^{Reviewed by Cursor Bugbot for commit e113750. Configure here.}

[cesarenaldi]

I found this open request for native uv.lock support: googleapis/release-please#2561. It suggests using release-please’s extra-files TOML updater as a workaround:

"extra-files": [
  {
    "type": "toml",
    "path": "uv.lock",
    "jsonpath": "$.package[?(@.name.value=='polymarket-client')].version"
  }
]

Would that approach work here and let us avoid the additional workflow job?

[kartojal]

I found this open request for native uv.lock support: googleapis/release-please#2561. It suggests using release-please’s extra-files TOML updater as a workaround:

"extra-files": [
  {
    "type": "toml",
    "path": "uv.lock",
    "jsonpath": "$.package[?(@.name.value=='polymarket-client')].version"
  }
]

Would that approach work here and let us avoid the additional workflow job?

Yes, way more clean, closing in favor of #255