Add B10 API spec drift rule to connector review mixin (#118)

## Summary

The connector review mixin covered *newly added* endpoints (B7, B8) but
had no criterion for an *existing* endpoint being changed. A version or
path swap (`/v1/users` → `/v2/users`), a renamed ID field, or a changed
pagination style could pass review unflagged — the downstream rules (B1,
B3) only catch the symptom if the reviewer connects the dots.

B10 closes that gap and ties both cases to the `build-openapi-spec.md`
skill.

## The rule

- **Trigger-gated.** Fires only when the diff changes or adds an API
endpoint — endpoint constants, request paths, base URL, or the
request/response structs bound to a call. Explicit instruction not to
raise it otherwise, so it stays quiet on unrelated PRs.
- **Endpoint changed** → compare the new request/response shape against
the checked-in `spec/openapi.json`. Any schema difference (path/version
change, field added/removed/renamed/retyped, ID field change, pagination
style change) is reported as `blocking-correctness`. If
`spec/openapi.json` wasn't updated in the PR it is stale, and that is
reported too — at `suggestion` severity when the schema itself looks
unchanged. Either way the author is told to regenerate the spec with the
skill. If no `spec/openapi.json` exists, it falls through to the
added-endpoint branch.
- **Endpoint added** → not a breaking change. Reported as a `suggestion`
asking the author to run the skill so `spec/openapi.json` covers the new
endpoint.

Severity names match the base prompt's vocabulary
(`blocking-correctness` / `suggestion`, see `base-pr-review.md`), so the
reviewer maps them to the right merge gate.

## Note for reviewers

`spec/openapi.json` and the `build-openapi-spec.md` skill both live in
the connector repos being reviewed, not here. If the skill is invoked
under a different name there, the rule text should be updated to match.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: Bencheng21

.github/actions/pr-review/prompts/mixins/connector.md

@@ -107,6 +107,19 @@ Criteria:
 - B7: New required OAuth scopes
 - B8: New endpoints added to existing sync paths can be breaking when they require new scopes or permissions
 - B9: Safe changes: display name changes, adding new resource types, adding trait options, adding pagination
+- B10: API spec drift. Trigger this rule only when the diff changes or adds an API endpoint
+  (endpoint constants, request paths, base URL, or the request/response structs bound to a call).
+  Do not raise it for unrelated changes.
+  - Endpoint changed: compare the new request and response shape against the checked-in
+    `spec/openapi.json`. If the schema differs — path or version changed, fields added,
+    removed, renamed, or retyped, ID field changed, or pagination style changed — report it as
+    a `blocking-correctness` breaking change. If `spec/openapi.json` was not updated in this
+    PR, it is now stale: report that as well, at `suggestion` severity when the schema looks
+    unchanged. In every changed-endpoint case, tell the author to regenerate
+    `spec/openapi.json` by running the `build-openapi-spec.md` skill. If no
+    `spec/openapi.json` exists, treat it as the added-endpoint case below.
+  - Endpoint added: not a breaking change. Report a `suggestion` asking the author to run the
+    `build-openapi-spec.md` skill so `spec/openapi.json` covers the new endpoint.
 
 Breaking connector changes should be gated behind opt-in config where possible, called out in
 the PR description, and paired with documentation updates.