Description
The gh-aw compiler incorrectly prepends the repository name to local file paths within {{#runtime-import ...}} macros when compiling a shared workflow. Specifically, when compiling a workflow inside a centralized repository named .github, it changes the intended path from .github/workflows/readme-pr-agent.md to .github/.github/workflows/readme-pr-agent.md. This breaks the runtime import when a caller repository tries to execute the workflow, as the agent attempts to resolve a nested .github/.github directory that doesn't exist in the caller's workspace.

Reproduction
Workflow source (readme-pr-agent.md prior to compilation):
{{#runtime-import .github/workflows/readme-pr-agent.md}}

gh-aw version: v0.50.3
Steps:

1. Create a shared organizational repository literally named .github.
2. Place a workflow markdown file (e.g., readme-pr-agent.md) inside its .github/workflows/ directory.
3. Run gh aw compile .github/workflows/readme-pr-agent.md from within the .github repository.
4. Set up a different repository (the caller) to trigger this shared workflow via workflow_call.
5. Trigger the workflow via a PR in the caller repository.
6. The activation job fails during the "Interpolate variables and render templates" step because it is searching for the duplicated path.

Evidence from logs
From the activation job of the failed run:
ERR_API: Failed to process runtime import for .github/.github/workflows/readme-pr-agent.md: ERR_SYSTEM: Runtime import file not found: .github/workflows/readme-pr-agent.md

Suspected root cause
The compiler appears to be resolving the {{#runtime-import}} path relative to the shared repository's root directory and erroneously injecting the repository's name into the compiled output.

Because the shared repository happens to be named .github, the compiler outputs .github/.github/.... If I had compiled this exact same workflow file inside a repository named <enterprise-name>, it would have compiled the macro as {{#runtime-import .github/workflows/readme-pr-agent.md}}. The compiler should not be injecting the source repository's name into a local runtime import that is meant to be resolved in the calling repository's workspace.

File Details
Looking directly at the compiled readme-pr-agent.lock.yml file, the compiler clearly altered the macro and propagated the duplicated folder structure into the bash script:

GH_AW_PROMPT_EOF
cat << 'GH_AW_PROMPT_EOF'
{{#runtime-import .github/.github/workflows/readme-pr-agent.md}}
GH_AW_PROMPT_EOF
} > "$GH_AW_PROMPT"

Expected behavior
When compiling a workflow, local paths inside {{#runtime-import ...}} should be left intact (e.g., {{#runtime-import .github/workflows/readme-pr-agent.md}}) so that they correctly resolve against the root of the caller repository at runtime, regardless of what the shared template repository is named.

Environment

• gh-aw: v0.50.3
• Repo: private enterprise repo (shared repo specifically named .github)
• Engine: copilot