Do not Schedule Upstream-Only Workflows and Jobs in Forks

Problem

Running GitHub Actions in an OpenVMM fork schedules workflows and jobs that depend on infrastructure available only to microsoft/openvmm. These jobs fail, remain queued indefinitely, or block otherwise runnable checks.

Affected workloads include:

• Checkin jobs that require Microsoft 1ES self-hosted runner pools.
• The PR quick-check job, which uses a self-hosted runner and blocks all downstream checkin jobs.
• Publishing documentation to openvmm.dev.
• Refreshing the internal VSO mirror.
• Uploading Petri results to the OpenVMM Azure storage account.
• OpenHCL binary-size checks that retrieve baseline workflow runs and artifacts from microsoft/openvmm.

The generated PR, release-PR, and CI workflows currently contain dozens of self-hosted jobs. Forks do not have access to those runner pools, repository secrets, Azure identities, internal services, or upstream Actions artifacts.

Reproduction

1. Create an OpenVMM fork and enable GitHub Actions.
2. Push to a configured branch or open a pull request within the fork.
3. Observe the OpenVMM workflows.

Jobs requiring upstream-owned resources either remain pending, fail authentication, or prevent the aggregate checkin gate from reporting a useful result.

Expected behavior

• Workflows and jobs that require upstream-only infrastructure do not run in forks.
• Checks that can run using GitHub-hosted infrastructure continue to run.
• Skipped upstream-only jobs do not cause aggregate status checks to fail or remain pending.
• Existing behavior in microsoft/openvmm, including draft-PR and release-label conditions, remains unchanged.