Provider-scoped engine.model compiles cleanly but is rejected by the bundled AWF at runtime

**Versions:** gh-aw v0.82.12 (strict mode), bundled AWF v0.27.35, Copilot engine 1.0.70.

## Summary

The compiler accepts a provider-scoped exact model name in `engine.model`, resolves it against the model catalog, and emits a lock file, but the AWF firewall that the same lock file launches rejects that model at engine startup. The compiler produces a workflow its own bundled firewall is guaranteed to refuse.

## Reproduction

Frontmatter:

```yaml
engine:
id: copilot
model: copilot/gpt-5.6-sol
bare: true
```

`gh aw compile` succeeds with 0 errors and 0 warnings in strict mode, consistent with the model alias specification, which lists a provider-scoped exact name as a valid `engine.model` (section 4.2, "Provider-scoped exact name: `copilot/gpt-5`") and resolves it via catalog exact match (section 8.3 step 3). The generated lock file sets `COPILOT_MODEL: copilot/gpt-5.6-sol`.

At runtime the agent job fails immediately:

```
[ERROR] Error: model 'copilot/gpt-5.6-sol' is unsupported or unrecognized by this AWF version.
```

Example runs: tenzir/content run 29612022146, tenzir/news run 29604447147.

## Analysis

The AWF api-proxy (`enableTokenSteering: true`) validates the requested model against the keys of the generated `apiProxy.models` alias map. The compiler only writes alias-map entries for the built-in aliases plus any `models:` frontmatter, never for the resolved `engine.model` itself. Alias keys must not contain `/` per the same specification (section 7.3), so no provider-scoped identifier can ever match an alias key: every provider-scoped `engine.model` that the compiler accepts fails at runtime under the firewall.

The only working configuration today is a bare alias name plus an explicit `models:` registration, for example:

```yaml
engine:
id: copilot
model: gpt-5.6-sol

models:
gpt-5.6-sol:
- copilot/gpt-5.6-sol
```

## Suggested remediation

Either of:

1. When `engine.model` is provider-scoped, have the compiler add an implicit self-alias to the generated steering map (one entry in `apiProxy.models`), so the accepted syntax also runs.
2. If provider-scoped `engine.model` is not meant to be supported with the firewall enabled, reject it at compile time with a hint to register a `models:` alias, instead of emitting a lock file that fails at engine startup.

Option 1 seems preferable since the specification explicitly documents the provider-scoped form for `engine.model`.

Start with gh aw compile's engine.model resolution and the generated apiProxy.models steering map, then compare the lock file with the bundled AWF startup validation. Done means provider-scoped engine.model either runs successfully under the firewall or is rejected during compilation with the documented models alias guidance.

Written by the indexing model from the issue text.