ci(release-please): sync uv.lock after version bump

[omercnet]

Why

The release-please PR (#1446) is failing every CI job with:

The lockfile at `uv.lock` needs to be updated, but `--locked` was provided.
To update the lockfile, run `uv lock`.

Root cause: release-please bumps version in pyproject.toml (1.13.0 → 2.0.0) but doesn't touch uv.lock. Since uv.lock records the project's own version (the [[package]] name = "descope" entry), uv sync --locked fails the integrity check on the next CI run.

Reproduced locally:

sed -i 's/^version = "1.13.0"/version = "2.0.0"/' pyproject.toml
uv sync --all-extras --locked
# → "The lockfile at `uv.lock` needs to be updated, but `--locked` was provided"
uv lock
# → "Updated descope v1.13.0 -> v2.0.0"
uv sync --all-extras --locked   # passes

What

Add a sync-uv-lock job after release-please-action that:

1. Reads the PR object from release-please-action's pr output and extracts headBranchName.
2. Runs only when a release PR was opened/updated (pr_branch != '').
3. Checks out the release-please PR branch using the same GitHub App token.
4. Runs uv lock to re-sync the project version in uv.lock.
5. Commits and pushes back to the PR branch only if uv.lock actually changed.
6. Uses the App's bot identity for the commit so it appears alongside release-please's own commits.

The push uses the App token (not GITHUB_TOKEN), so PR CI re-triggers automatically with the fixed lockfile.

If release-please regenerates the PR later (e.g. new commits land on main), the workflow re-runs on the next push to main and re-applies the sync — the lock stays in sync without manual intervention.

Out of scope

• The publish job is unchanged — it runs at tag time, after the PR is merged, where uv.lock is already fixed.
• We don't try to add uv.lock to release-please's extra-files because release-please's TOML updater can't address [[package]] name = "descope" array entries cleanly.

Verification

• Workflow YAML lints clean (actionlint).
• Local reproduction shows uv lock is the exact remediation needed.
• After this lands and release-please regenerates chore: release 2.0.0 #1446, the PR's CI should go green.

[shuni-bot-dev]

🐕 Review complete — View session on Shuni Portal 🐾

[shuni-bot-dev]

🐕 Shuni's Review

Adds a sync-uv-lock job after release-please that re-locks uv.lock whenever the release PR bumps the project version, then commits via the App token so PR CI re-triggers.

No issues found — good bones! The conditional plumbing (if: steps.release.outputs.pr → pr_branch output → downstream != '' gate), App-token-scoped checkout/push, and idempotent git diff --quiet guard are all sound. Failure modes (e.g. release-please force-push racing with this push) fail safely rather than corrupting state. Woof!

[Copilot]

Pull request overview

Adds a post-processing step to the release automation so release-please PRs don’t fail CI when pyproject.toml version bumps invalidate uv.lock.

Changes:

• Expose the release-please PR head branch as a job output (pr_branch) by extracting it from the release-please-action pr JSON output.
• Add a sync-uv-lock job that checks out the release PR branch, runs uv lock, and commits/pushes uv.lock back to the PR branch only when it changed.
• Use the GitHub App token + bot identity for the commit/push so the PR CI re-triggers.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

Coverage report

The coverage rate went from 98.37% to 98.37% ➡️

None of the new lines are part of the tested code. Therefore, there is no coverage data about them.

[omercnet]

Superseded by #1518 — much simpler fix using release-please's native extra-files jsonpath support per googleapis/release-please#2561. 5 lines of config instead of a 55-line follow-up workflow job, no GitHub App token push-back required.