Refactor *.cjs scripts to support SideRepoOps pattern natively

[yskopets]

Background

When using the SideRepoOps pattern, agentic workflows that respond to slash_command events (e.g., issue_comment) must be augmented to handle events delivered from the target repository into the side repository via the repository_dispatch mechanism.

Today, gh-aw compile generates *.lock.yml files that only handle events natively — they do not support the case where the same event payload arrives wrapped in a repository_dispatch envelope from a target repo.

Problem

*.cjs scripts implementing steps such as Compute current body text, Add comment with workflow run link, etc. do not natively support events delivered from another repo.

In many cases it's possible to work around this by monkey-patching the script invocation code in the auto-generated step, for example:

      - name: Compute current body text
        id: sanitized
        uses: actions/github-script@373c709c69115d41ff229c7e5df9f8788daa9553 # v9
        with:
          script: |
            // monkey-patch arguments into the `*.cjs` script to make it use information delivered over `repository_dispatch`

            const eventName = context.payload.action;
            const repo = { owner: context.payload.client_payload.repository.owner.login, repo: context.payload.client_payload.repository.name };
            const actor = context.payload.client_payload.sender.login;
            const payload = context.payload.client_payload;

            const patchedContext = { ...context, eventName: eventName, repo: repo, actor: actor, payload: payload };

            const { setupGlobals } = require('${{ runner.temp }}/gh-aw/actions/setup_globals.cjs');
            setupGlobals(core, github, patchedContext, exec, io, getOctokit);

This workaround works for most scripts, but not all.

Concrete failure: add_workflow_run_comment.cjs

Some scripts need to refer to two different repos simultaneously:

1. The side repo (where the workflow is running) — e.g., to generate a workflow run URL
2. The target repo (where the original event occurred) — e.g., to post a comment or generate a comment link

add_workflow_run_comment.cjs currently uses a single context.repo for both purposes. When we override context.repo to point to the target repo (so the comment is posted in the right place), the workflow run URL breaks because it now points to the wrong repo.

Our current workaround is to:

1. Add a workflowRepo field to patchedContext before overriding repo with the target repo
2. Patch the compiled .cjs file at runtime using sed to replace buildWorkflowRunUrl(context, context.repo) with buildWorkflowRunUrl(context, context.workflowRepo ?? context.repo)

This is fragile and couples us to the internal structure of the compiled scripts.

Expected Outcome

• *.cjs scripts are refactored to make a clear distinction between:
  1. The workflow repo (where the workflow run lives) — used for workflow run links
  2. The event repo (where the triggering event occurred) — used for comments, reactions, etc.
• Scripts accept an explicit workflowRepo / eventRepo separation rather than relying on a single context.repo

Long-term Goal

When using the SideRepoOps pattern, gh-aw compile should generate a *.lock.yml that handles repository_dispatch-wrapped events from the target repo out-of-the-box, without requiring manual augmentation of the lock file.

[pelikhan]

@copilot refactor helpers that handle context in own file and handle the multiple invocation possible sites: native / workflow_dispatch / repository_dispatch