model: at workflow root silently drops an imported engine.auth (OIDC/WIF) config, falls back to API-key auth with no warning

### Description

When a workflow both imports an engine block (e.g. `imports: - shared/engine.md` where the shared file declares `engine.auth`) **and** declares a top-level `model:` key of its own, the compiler silently drops the imported `engine.auth` config entirely — no warning, no error, compiles clean — and falls back to the default (API-key) auth engine instead of the OIDC/WIF auth the import was meant to provide.

Confirmed on `v0.88.7`.

### Repro

`shared/engine.md`:
```yaml
---
engine:
id: claude
auth:
type: github-oidc
provider: anthropic
federation-rule-id: ${{ vars.ANTHROPIC_FEDERATION_RULE_ID }}
service-account-id: ${{ vars.ANTHROPIC_SERVICE_ACCOUNT_ID }}
organization-id: ${{ vars.ANTHROPIC_ORGANIZATION_ID }}
workspace-id: ${{ vars.ANTHROPIC_WORKSPACE_ID }}
---
```

Workflow A (no `model:`):
```yaml
---
imports:
- shared/engine.md
permissions:
id-token: write
---
```
Compiles with `AWF_AUTH_TYPE: github-oidc` and the rest of the `AWF_AUTH_*` env vars wired in the agent step — correct.

Workflow B (same import, `model:` added at root, position doesn't matter — tried immediately after `imports:` and after `permissions:`, same result):
```yaml
---
imports:
- shared/engine.md
model: claude-sonnet-4-6
permissions:
id-token: write
---
```
Compiles successfully (no warning/error), `model` is correctly recorded in the compiled metadata (`agent_model: claude-sonnet-4-6`), but **`AWF_AUTH_TYPE` and every other `AWF_AUTH_*` var are entirely absent** from the compiled lock file. The workflow instead falls back to `secrets.ANTHROPIC_API_KEY` (a "Validate ANTHROPIC_API_KEY secret" step gets added) even though the workflow never asked for API-key auth and has no `engine.auth` of its own.

### Impact

This is worse than a compile error because it's silent: a repo relying on OIDC/WIF for its Anthropic auth (to avoid holding a long-lived API key secret) can add `model:` to pin a specific model version, and the workflow will keep "working" at a glance — right up until it fails at runtime with something like a missing `ANTHROPIC_API_KEY` secret, or (if that secret happens to also exist for unrelated reasons) silently authenticates via API key instead of the intended WIF/OIDC path, with no diagnostic pointing at the actual cause.

### Suggested fix

Either:
- Make top-level `model:` merge into an imported `engine:` block instead of implicitly constructing a new, separate engine definition that discards the import's `auth`; or
- If `model:` + an imported `engine.auth` genuinely can't be merged, fail the compile with a clear error (similar to the existing "mapping key already defined" duplicate-key error) rather than silently compiling a workflow with different auth than what was imported.

### Evidence

Discovered while working on github/gh-aw#60871's originating PR — see that issue for the unrelated Playwright browser-path bug found in the same workflow. Root cause here confirmed by directly diffing compiled output with/without a `model:` key, `imports:` and shared engine file held constant.

Start with the workflow front matter, shared/engine.md, and the compiler path that handles imported engine blocks and a top-level model key. Compare the compiled lock file and agent-step environment for the two provided workflows. Done means imported auth is preserved when model is set, or compilation fails with a clear diagnostic instead of falling back silently.

Written by the indexing model from the issue text.