chore(release): retarget release automation from main to v3

[miguelg719]

What

Makes the frozen v3 branch a self-sufficient maintenance home for Stagehand 3.x, ahead of main becoming v4 (squash-merge of v4-spike). Follows the v2 freeze playbook.

• release.yml — trigger on push to v3; the refs/heads/main guards on the browse publish steps follow.
• package.json — changeset publish --tag v3: 3.x maintenance releases publish under the v3 dist-tag so they never steal latest back from 4.x. (browse keeps --tag latest — it lives only on this branch and its latest should keep advancing.)
• release-cli.yml — allow the browse release dispatch from v3.
• stagehand-server-v3-release.yml — trigger on push to v3.
• stagehand-server-v4-release.yml — retargeted for consistency, but note it references packages/server-v4/ which does not exist in this tree; it looks vestigial and could be deleted in a follow-up.
• stainless.yml / external-contributor-pr.yml — these run from the base branch's workflow copy, so their hardcoded main refs would misfire for PRs targeting v3; retargeted.
• .changeset/config.json — baseBranch: v3.

Why now

v3 was just cut from main's tip (7566804ed), replacing v3-legacy, and protected via ruleset. Without this change, pushes to v3 trigger no release automation and a future 3.x patch would publish as latest.

---

Summary by cubic

Retargeted release automation from main to v3 so Stagehand 3.x can ship maintenance releases independently of v4. Pushes to v3 now trigger releases, npm publishes use the v3 dist-tag, and the unused v4 server workflows are removed.

• Refactors
  • Pointed release workflows to v3 and updated browse flow: release.yml guards run on v3 and the canary step checks out the triggering commit; release-cli.yml now opens browse release PRs against v3.
  • Made external-contributor-pr.yml base-aware (derive from source PR’s base.ref) and updated status messages; adjusted stainless.yml merge gate to v3.
  • Set .changeset/config.json baseBranch to v3; changed package.json release script to changeset publish --tag v3 (browse continues to publish under latest on this branch).
  • Deleted stagehand-server-v4-release.yml and stagehand-server-v4-sea-build.yml.

^{Written for commit c9f105e. Summary will update on new commits.}

[changeset-bot]

⚠️ No Changeset found

Latest commit: c9f105e

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[cubic-dev-ai]

All reported issues were addressed across 8 files

Architecture diagram

sequenceDiagram
    participant GH as GitHub
    participant Rel as Release Workflow
    participant RelCli as Release CLI Workflow
    participant S3 as Server v3 Workflow
    participant S4 as Server v4 Workflow
    participant CS as Changesets Action
    participant NPM as npm Registry
    participant Browse as Browse Package

    Note over GH,Rel: Push event to v3 (baseBranch) triggers release automation

    GH->>Rel: push to refs/heads/v3
    GH->>RelCli: push to refs/heads/v3
    GH->>S3: push to refs/heads/v3 (paths: .changeset/**)
    GH->>S4: push to refs/heads/v3 (paths: .changeset/**)

    Note over S4: Dormant - references packages/server-v4/ (nonexistent)

    Rel->>Rel: Checkout repo, install deps
    Rel->>CS: Run changesets action (baseBranch: v3)
    CS->>Rel: Create/update version PR

    Note over Rel: After version PR merges, publish runs

    Rel->>Rel: Run release script (package.json)
    Rel->>CS: changeset publish --tag v3
    CS->>NPM: Publish core packages with dist-tag v3
    NPM-->>Rel: Success (packages tagged v3, not latest)

    alt Browse changes detected
        Rel->>Rel: Check if browse publish needed (ref: v3)
        Rel->>Browse: Prepare tarball
        Browse->>NPM: npm publish --tag latest (browse only)
        NPM-->>Rel: Browse published to latest
    else No browse changes
        Rel->>NPM: Publish canary (if needed)
    end

    Note over RelCli: Separate workflow for browse release PRs
    RelCli->>CS: Create/update browse release PR (baseBranch v3)
    CS-->>RelCli: PR ready
    RelCli-->>GH: PR created for browse release

    Note over S3: Server v3 release triggered on push to v3
    S3->>CS: Trigger server-v3 release (path-filtered)
    CS-->>NPM: Publish server-v3 if changesets present

    Note over GH: External contributor PR workflows now target v3 base

Loading

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[miguelg719]

Addressed the review in 019ad48..HEAD:

• Canary checkout: confirmed real — now git checkout ${{ github.sha }} so the canary always builds the triggering v3 commit, never a diverged main.
• release-cli PR base: confirmed — both --base main args and the PR body text now say v3.
• external-contributor claim path: made base-aware (pr.base.ref / fetched source-PR base) rather than hardcoding either branch. Caveat worth stating: the workflow_run claim job always executes the default branch's copy of this workflow, so this branch's copy is inert for that job today — and after the v4 merge, main won't carry this workflow at all, which kills the automated claim flow for v3-targeted external PRs. The base-aware code is correct wherever it runs; if we want the claim flow to survive the v4 merge, the workflow needs a home on the new main (follow-up decision).
• Status messages: now interpolate pr.base.ref.
• server-v4 workflows: deleted stagehand-server-v4-release.yml and its sea-build companion — they reference packages/server-v4, which doesn't exist in this tree.