Lock file integrity check should resolve the lock file from the reusable workflow source repository

[jaroslawgajewski]

Problem

When a reusable workflow compiled by gh-aw is invoked from another repository, the lock file integrity check may look for the .lock.yml file in the caller repository instead of the repository that actually contains the reusable workflow.

This causes the activation phase to fail even though the referenced reusable workflow and its lock file are valid.

Current behavior

The workflow runs the lock file/frontmatter integrity check in the execution context of the caller repository.

In cross-repository reusable workflow scenarios, this can result in:

the source .md and .lock.yml being resolved against the wrong repository
a 404 Not Found when fetching the lock file
ERR_CONFIG / integrity-check failure before the agent starts

Expected behavior

The integrity check should verify the lock file against the repository and ref that contain the reusable workflow itself, not only the repository where the workflow is being executed.

This should work for:

same-repo execution
cross-repo reusable workflow calls
org-level rollout patterns where reusable workflows are centrally maintained

testing scenario

source workflow located in org A / repository A - central reusable workflows repo
triggering workflow located in org B / repository B - consumer

name: WF Name

on:
  schedule:
    - cron: '35 23 * * 1-5'
  workflow_dispatch:

permissions:
  contents: read
  issues: write
  pull-requests: read

jobs:
  run:
    uses: OrgA/repoA/.github/workflows/reusableworkflow.lock.yml@v1
    secrets: inherit