Description

Workflows using the labels: filter in the on: block (e.g., labels: [my-label]) fail on every push to the default branch with:

"This run likely failed because of a workflow file issue."

The labels: filter correctly shows unmatched label events as Skipped (⊘), but push events that re-evaluate the workflow file cause a Failed (❌) result instead.

Reproduction

1. Create a workflow with an issues: [labeled] trigger and a labels: filter:

on:
  issues:
    types: [labeled]
  labels: [my-label]

2. Compile with gh aw compile
3. Push any commit to the default branch (even one unrelated to the workflow file)
4. Observe that the compiled .lock.yml triggers a run on the push event and fails with a "workflow file issue" error

Expected Behavior

Push events should either:

• Not trigger the workflow at all (since push is not a declared trigger), or
• Show as Skipped (⊘) rather than Failed (❌)

Actual Behavior

Every push to the default branch triggers a failed run for each workflow using the labels: filter. This creates significant noise in the Actions tab — repositories with multiple labels:-filtered workflows accumulate dozens of spurious failures per day.

Environment

• gh-aw version: v0.71.5

Additional Context

The labels: key appears as a top-level entry under on: in the compiled .lock.yml file. GitHub Actions does not recognize this as a valid event type or filter, which likely causes the parse-level failure on push-triggered validation runs.

A possible fix would be to compile labels: into a job-level if: condition or into the existing activation job logic, so that GitHub Actions never encounters an unrecognized top-level key in the on: block.