## Which issue does this PR close?

Related to apache#25148.

## Rationale for this change

Fork CI can fail waiting for a macOS runner before any tests start,
blocking the `Rust (fork)` check.

## What changes are included in this PR?

Skip macOS tests in fork repositories, register the condition with the
existing workflow validator, and document the exclusion in the
contributor guide. Upstream coverage is unchanged, including the
required merge-queue check, following apache/arrow-rs#11991.

Windows remains unchanged; its job is already disabled.

## What is the testing strategy for this PR?

Existing workflow-validator tests, all-features Clippy, and all checks
in `./dev/rust_lint.sh` pass. No new tests: the existing validator
checks exact job conditions against the policy table.

## Are there any user-facing changes?

Contributors no longer need a macOS runner for fork CI. No runtime or
API changes.

# Which issue does this PR close?

- Part of apache#11469

# Rationale for this change

apache#11991 stopped running macOS tests in forks. @Jefffrey
[suggested](apache#11991 (comment))
moving the Windows job to the merge queue as well, because few changes
affect Windows and every fork push currently spends about 9 minutes on
it.

# What changes are included in this PR?

The Windows job now uses the same guard as the macOS job, so it no
longer runs on fork pushes, fork manual runs, or PRs inside a fork. The
CI validator and contributor docs are updated to match.

This is not strictly merge queue only. Windows still runs on
same-repository PRs, release-branch PRs, and upstream manual runs. The
merge queue only covers the default branch, so a `merge_group` guard
would leave release-branch PRs with no Windows testing. Contributors
working from forks do get merge queue only behavior, since upstream runs
of fork PRs already skip Windows. Of the last 200 PRs merged to `main`,
the only same-repository ones were 20 from dependabot.

Two tradeoffs:

- Upstream runner use does not change. The savings are all on
contributors' forks.
- Contributors first see a Windows failure when their PR is in the
queue, and cannot run Windows manually from their fork.

# Are these changes tested?

The CI validator now pins the Windows guard, and a new regression case
checks that restoring the old guard on the Windows job fails validation.
The guard itself only runs on GitHub, so this PR's fork run should skip
Windows and its queue run should execute it.

AI assistance was used for the workflow, validator, regression test, and
documentation changes.

# Are there any significant user-facing changes?

No

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

Co-authored-by: Claude Opus 5.5 <[email protected]>