Recognize Cursor Origin (origin.cursor.com) as a VCS provider #146

Summary

linear-release sync fails on repositories hosted on Cursor Origin because the git remote hostname is origin.cursor.com, which hostToProvider() does not recognize. The GraphQL releaseSync mutation then receives input.repository.provider: null and rejects it:

Variable "$input" got invalid value null at "input.repository.provider"; Expected non-nullable type "String!" not to be null.

This is the same failure mode as #118 (custom GitLab/GitHub hostnames) and #48 (*.ghe.com). Origin is a first-class git host, not a self-hosted GitHub, so claiming github is only a workaround.

Environment

• linear-release v0.14.0 (reproduced) and v0.18.0 (workaround via LINEAR_VCS_PROVIDER)
• CI: Depot GitHub Actions runners
• Remote after checkout: https://origin.cursor.com/pewresearch/prc-platform.git
• Clone URL shape: https://origin.cursor.com/{owner}/{repo}.git (docs)

Reproduction

git clone https://origin.cursor.com/acme/example.git
cd example
LINEAR_ACCESS_KEY=... linear-release sync --verbose --release-version=1.0.0 --base-ref=<tag>

Observed: commit scan and empty-range baseline handling succeed; the mutation fails on repository.provider.

Workaround today

v0.15.0 added LINEAR_VCS_PROVIDER. Setting LINEAR_VCS_PROVIDER=github unblocks the mutation. That is lossy:

• Linear stores provider: github for an Origin repo.
• repository.url is the Origin URL (https://origin.cursor.com/...), which Linear’s GitHub integration cannot fetch.
• Origin pull-request numbers in squash titles (Title (#24)) look like GitHub PRs but live on cursor.com/codebase/.../pull/..., so Linear cannot resolve issues attached only via the Origin PR.

Issue identifiers in commit subjects / branch names (PRC-123) still attach. PR-number linking does not.

Suggested fix

1. CLI detection. Treat origin.cursor.com (and, if useful, cursor.com) as a known host in hostToProvider(), the same way *.ghe.com was added in Recognize *.ghe.com hosts as GitHub Enterprise Cloud #48. Today the only documented enum values are github | gitlab | bitbucket. If the API cannot accept a new origin value yet, detecting the host and mapping it to a documented provider is still better than sending null.
2. First-class Origin provider. Prefer a real origin (or cursor) provider so Linear can store Origin repo URLs and resolve Origin PR numbers, instead of forcing teams onto LINEAR_VCS_PROVIDER=github.
3. PR number resolution. Origin squash/merge messages use the GitHub-like Title (#N) form. Resolving those against Origin rather than GitHub would restore the “issues linked only on the PR” path described in the README.

Happy to test a build against origin.cursor.com/pewresearch/prc-platform.