Engine-agnostic secret name for BYO-endpoint API keys

We run gh-aw agents behind an OpenAI/Anthropic-compatible proxy, with callers in several consumer repos passing a short-lived key via `workflow_call` secrets. Over two days we migrated engines twice (codex → claude, with a copilot BYOK experiment in between), and each migration changed the *declared secret name* — `CODEX_API_KEY`/`OPENAI_API_KEY` → `ANTHROPIC_API_KEY` → `COPILOT_PROVIDER_API_KEY`.

Because `workflow_call` fails at startup on any undeclared secret, that name is effectively part of the reusable workflow's public interface. Every engine change forced a coordinated rename across six caller files in four repos, with an unavoidable breakage window: old callers fail against the new lock ("Invalid secret, X is not defined in the referenced workflow") and new callers fail against the old one. The engine choice — which callers otherwise never need to know about — leaks into every consumer.

Ask: accept a generic secret alias across engines — e.g., declare `AGENT_API_KEY` in every engine's `workflow_call` block and validate/route it to the engine's native env (`CODEX_API_KEY`, `ANTHROPIC_API_KEY`, `COPILOT_PROVIDER_API_KEY`) with the native names still accepted for backward compatibility. With that, swapping `engine.id` in the workflow `.md` would be invisible to callers, and reusable-workflow authors could iterate on engines without cross-repo migrations.

Context: gh-aw v0.86.2; the migrations were otherwise smooth — the exchange job producing the key never changed, only the label on the envelope.

Start by locating the workflow .md files, their engine.id settings, and each workflow_call secret declaration. Trace how the declared secret is validated and routed to engine-native names; done means AGENT_API_KEY works across engines, native names remain accepted, and changing engine.id requires no caller migration.

Written by the indexing model from the issue text.