Expose AWF platform.type (ghec/ghes) via workflow frontmatter

[lpcox]

Summary

The AWF (Agentic Workflow Firewall) supports an explicit platform.type config option that declares the GitHub deployment type so AWF can apply the correct Copilot auth behavior (e.g. token vs Bearer Authorization prefix) without relying on host heuristics. Today this option is not exposed via gh-aw workflow frontmatter, so workflow authors have no way to declare their platform when compiling.

This issue proposes adding a frontmatter field that the compiler maps into the generated awf-config platform.type.

Background: what AWF supports

AWF's stdin config schema defines a platform block (vendored into gh-aw at pkg/workflow/schemas/awf-config.schema.json:683):

"platform": {
  "type": {
    "enum": ["github.com", "ghes", "ghec", "ghec-self-hosted"]
    // 'github.com' = GitHub.com (default)
    // 'ghes'       = GitHub Enterprise Server (on-premises)
    // 'ghec'       = GitHub Enterprise Cloud (*.ghe.com tenants)
    // 'ghec-self-hosted' = GHEC with self-hosted runners
  }
}

Internally this maps config.platform.type → AWF_PLATFORM_TYPE, which the api-proxy uses to decide the Copilot Authorization prefix.

The gap in gh-aw

The compiler does not surface or emit this option:

• pkg/workflow/awf_config.go (the awf-config builder) has no platform references — the block is never populated.
• Searching the repo for platformType / PlatformType / AWF_PLATFORM_TYPE returns 0 results.
• The platform block in awf-config.schema.json is only a vendored copy of the firewall schema; it is not wired to any frontmatter key.
• The existing GHES support (ADR-40030, pkg/workflow/ghes_host_step.go) only auto-detects GH_HOST from the git origin remote for gh-backed compile checks and action pinning. It does not feed the firewall's auth platform.type.

Net result: a workflow author cannot tell the firewall "this runs on GHES/GHEC" — the only ways to set it today are the AWF-direct paths (stdin config platform.type or AWF_PLATFORM_TYPE env var), neither reachable from a .md workflow.

Proposal

Add an optional frontmatter field that the compiler maps to awf-config platform.type. Suggested shape (under the firewall/engine config — exact placement TBD by maintainers):

engine:
  id: copilot
  firewall:
    platform: ghes   # one of: ghec | ghes | ghec-self-hosted

Semantics:

• Unspecified (default): assumes GitHub.com–hosted (github.com). No change to current behavior.
• ghec — GitHub Enterprise Cloud (*.ghe.com tenants).
• ghes — GitHub Enterprise Server (on-premises).
• (ghec-self-hosted may be included for parity, but the three above cover the primary need.)

When set, the compiler emits platform.type into the generated awf-config so AWF skips heuristic detection and applies the correct Copilot auth prefix deterministically.

Why this matters

Host heuristics can be ambiguous in some deployments (custom COPILOT_API_TARGET, GHEC tenants, etc.), leading to wrong Authorization prefixes (Bearer vs token) and 400 Authorization header is badly formatted errors. An explicit frontmatter knob gives authors a deterministic escape hatch that matches what AWF already supports natively.

Acceptance criteria

• A frontmatter field maps to awf-config platform.type.
• Omitting it defaults to github.com-hosted (no behavior change).
• Accepts ghec, ghes (and optionally ghec-self-hosted).
• Compiler emits the corresponding platform.type in the generated awf-config / lock file.
• Frontmatter schema + docs updated; validation rejects unknown values.

References

• AWF schema block: pkg/workflow/schemas/awf-config.schema.json:683-694
• awf-config builder (no platform emission today): pkg/workflow/awf_config.go
• GHES host auto-detect (unrelated to auth platform): ADR-40030, pkg/workflow/ghes_host_step.go