feat: allow ${{ github.aw.import-inputs.* }} expressions in frontmatter imports section #25125

Note: This issue was filed by Claude Code on behalf of @yskopets.

Problem

${{ github.aw.import-inputs.* }} expressions are supported inside an imported workflow's body — in tools:, safe-outputs:, etc. — but not in the imports: section of that same workflow's frontmatter.

This makes it impossible to build composable shared workflows that forward their own inputs to other shared workflows they depend on.

Minimal Example

Consider a shared workflow shared/daily-report.md that bundles repo-memory and discussion publishing into a single reusable component:

---
# shared/daily-report.md
import-schema:
  branch-name:
    type: string
    required: true
    description: "Branch name for repo-memory storage"
  target-repo:
    type: string
    required: true
    description: "Target repo for publishing discussions"
  title-prefix:
    type: string
    required: true
    description: "Title prefix for created discussions"

imports:
  - uses: shared/repo-memory-standard.md
    with:
      branch-name: ${{ github.aw.import-inputs.branch-name }}   # ❌ not resolved
      description: "Daily report results"
  - uses: shared/daily-audit-discussion.md
    with:
      target-repo: ${{ github.aw.import-inputs.target-repo }}   # ❌ not resolved
      title-prefix: ${{ github.aw.import-inputs.title-prefix }} # ❌ not resolved
      expires: 3d
---

A consuming workflow would then write:

---
imports:
  - uses: shared/daily-report.md
    with:
      branch-name: "memory/my-workflow"
      target-repo: "myorg/myrepo"
      title-prefix: "[my-workflow] "
---

Currently, this silently uses unresolved literal strings (or errors out), forcing every consuming workflow to import shared/repo-memory-standard.md and shared/daily-audit-discussion.md individually with hardcoded with: values — defeating the purpose of shared workflows.

Expected Behavior

${{ github.aw.import-inputs.* }} expressions are resolved before the imports: section is processed, so parameterized shared workflows can forward inputs to their own nested imports.

Why This Matters

Right now the composability ceiling for shared workflows is one level deep: a shared workflow can use its inputs in tools: and safe-outputs:, but it cannot pass those inputs to another shared workflow it depends on. Supporting expression interpolation in imports: would unlock multi-level composition and significantly reduce boilerplate in consumer workflows.