[Bug]: Fork PR CI fails after actions/checkout v6.1.0 security change

### Is there an existing issue for the same bug?

- [x] I have checked the existing issues.

### Branch Name

main

### Commit ID

- MatrixOne CI entrypoint: `dde1e2616` and later `main`
- `matrixorigin/CI`: `177e363b8e160468fd7df970664adb9e3f7b6d8f`
- Last working `actions/checkout` v6.0.3 SHA: `df4cb1c069e1874edd31b4311f1884172cec0e10`
- Failing `actions/checkout` v6.1.0 SHA: `d23441a48e516b6c34aea4fa41551a30e30af803`

### Other Environment Information

- GitHub Actions event: `pull_request_target`
- PR source: fork repository
- MatrixOne workflow: `.github/workflows/entrypoint.yaml`
- Reusable workflows: `matrixorigin/CI@main`
- First confirmed failing run: https://github.com/matrixorigin/matrixone/actions/runs/29756799570

### Actual Behavior

All CI jobs that check out a fork PR head fail before MatrixOne code is built or tested. The checkout step reports:

```text
Refusing to check out fork pull request code from a 'pull_request_target' workflow.
This workflow runs with the base repository's GITHUB_TOKEN, secrets,
default-branch cache scope, and runner access.
```

Affected jobs include Ubuntu UT, ARM64 SCA, Compose BVT, Standalone BVT, Coverage, and other workflows that use:

```yaml
repository: ${{ github.event.pull_request.head.repo.full_name }}
ref: ${{ github.event.pull_request.head.ref }}
```

Secondary errors such as missing checkout directories, missing coverage files, and `mo-service has already crashed` are consequences of the checkout failure.

### Expected Behavior

Fork PRs should run the required CI checks under a security model that does not expose trusted repository credentials or privileged runner access to untrusted PR code.

Until that model is implemented, the existing CI needs a controlled temporary mitigation so fork PR validation can continue.

### Steps to Reproduce

```text
1. Open or synchronize a MatrixOne PR whose head repository is a fork.
2. MatrixOne's `pull_request_target` entrypoint invokes the reusable workflows from `matrixorigin/CI@main` with inherited secrets.
3. A reusable workflow runs `actions/checkout@v6` with the fork repository and branch.
4. Since the `v6` tag now resolves to v6.1.0, checkout rejects the operation before any build or test step starts.
```

### Additional information

#### Incident timeline

All times below are UTC on 2026-07-20:

- `15:14`: a successful fork PR job resolved `actions/checkout@v6` to `df4cb1c` (v6.0.3).
- `15:23`: `actions/checkout` v6.1.0 was published with a breaking fork-checkout safety default.
- `15:48`: the failing run resolved the same `@v6` reference to `d23441a` (v6.1.0).

The successful and failing jobs used the same MatrixOne CI workflow revision and runner image. The checkout action SHA was the relevant change.

Release: https://github.com/actions/checkout/releases/tag/v6.1.0

Comparison: https://github.com/actions/checkout/compare/df4cb1c069e1874edd31b4311f1884172cec0e10...d23441a48e516b6c34aea4fa41551a30e30af803

#### Immediate mitigation

Temporary hotfix: https://github.com/matrixorigin/CI/pull/394

The hotfix pins only checkout steps that fetch `github.event.pull_request.head.repo.full_name` to the last working v6.0.3 SHA. Fixed-repository checkouts remain on `@v6`.

This mitigation intentionally restores the previous behavior and therefore retains the existing security risk. It must not be treated as the final design.

#### Required long-term work

- [ ] Move execution of fork-controlled code to a `pull_request` workflow with read-only permissions and no inherited secrets.
- [ ] Keep `pull_request_target` limited to metadata, labels, authorization, and reporting; do not checkout or execute PR code there.
- [ ] Remove unnecessary `TOKEN_ACTION` usage for public repository checkout.
- [ ] Run fork CI on GitHub-hosted or isolated ephemeral runners without internal-network access or persistent credentials.
- [ ] Gate genuinely privileged tests by an approved exact head SHA and use short-lived, least-privilege credentials.
- [ ] Pin third-party actions and reusable workflows to immutable SHAs instead of floating major branches/tags.
- [ ] Apply the final model to maintained release branches as well as `main`.

#### Acceptance criteria

- Fork PRs can complete required UT/SCA/BVT checks.
- No trusted workflow directly executes fork-controlled code with inherited repository/environment secrets.
- Updating an action's floating tag cannot silently change CI security behavior.
- A PR synchronize/force-push cannot reuse approval granted to a previous head SHA.