Default ocr_version 'latest' changes review behavior even under a fully pinned Action reference

## Problem

Split out of #816 so that issue can close with the part everyone agrees on (SHA-pinning the internal `actions/*` references, #836). This issue tracks the remaining open design question.

With the Action fully SHA-pinned, review behavior still changes over time because the CLI is installed at run time with `ocr_version` defaulting to `latest`:

```bash
npm install -g "@alibaba-group/open-code-review@${OCR_VERSION}" # default: latest
```

A breaking or behavior-changing CLI release reaches every default-configured workflow immediately — including workflows whose owners deliberately pinned `uses: alibaba/open-code-review@` — and "run the same review as last week" is not reproducible without knowing to also pin `ocr_version`.

## Positions so far (from the #816 discussion)

**Maintainers** ([comment](https://github.com/alibaba/open-code-review/issues/816#issuecomment-5240732038)): keep `latest` as the default so most consumers pick up bug fixes and new detectors automatically; flipping the default would silently strand workflows on old CLI versions unless users bump `ocr_version` each release. Preference: make the pinning path more discoverable in the README instead.

**Reporter**: default the CLI version to the Action's own release (`v1.8.10` action → `ocr_version: 1.8.10`), keep `latest` as an explicit opt-in, and offer a floating major (`@v1`) so compatible fixes auto-follow while breaking changes require a deliberate `@v2`. Comparable actions mostly avoid unbounded `latest` for the tool itself (trivy-action pins an exact default; goreleaser defaults `~> v2`; codeql recommends `@v4` major floating) — detailed comparison in [#816](https://github.com/alibaba/open-code-review/issues/816#issuecomment-5241004371).

## Current state

#836 documents the dual pin (Action SHA + `ocr_version`) in a "Reproducible pinning" section of the GitHub Actions example README — the maintainers' discoverability suggestion. The default itself is unchanged; whether it should be is this issue.

No code change should land here until maintainers pick a direction.

Read the GitHub Actions example README's “Reproducible pinning” section and the linked #816 discussion, then inspect the workflow entry containing the npm install command. This issue is not ready for implementation: done depends on maintainers choosing a default-version policy, after which the workflow behavior and any supporting documentation should agree with that decision.

Written by the indexing model from the issue text.