engine: claude is selectable but cannot actually be used

[charlesgreen]

docs/setup.md does not offer engine: claude as an option. That is not an oversight in the docs. The engine cannot be used through the documented path at all, and the README currently says otherwise.

What is actually true

The adapter is real. internal/engine/claude/claude.go shells out to claude -p, has its own tests, and newRunner selects it when the config says engine: claude (cmd/simplycubed/main.go:199). The Runner seam works.

Everything around it still assumes Codex on Azure.

The CLI refuses to start without Azure credentials, whatever engine you pick. engineEnv() is called unconditionally in the setup path and hard-requires both variables, and codex.WriteConfig runs unconditionally right after it. Verified against a repo whose config says engine: claude:

$ simplycubed preflight --repo-dir .
error: AZURE_OPENAI_ENDPOINT is not set. ...
$ simplycubed run owner/repo#1 --repo-dir .
error: AZURE_OPENAI_ENDPOINT is not set. ...

The Actions path cannot run it at any setting. The reusable workflow installs only the Codex CLI (npm install -g @openai/codex, both jobs), never claude. azure-openai-endpoint and azure-openai-api-key are required inputs and secrets. There is no ANTHROPIC reference anywhere in the repository.

So the only configuration that reaches claude -p is a local CLI run, on a machine that already has claude authenticated, and has Azure credentials set that the Claude path never uses.

What the docs claim

README.md:201 says it "runs headless (claude -p) against whatever credentials that CLI is already configured with, so there is no second key to manage here." True about credentials, and it omits that Azure is still mandatory and that Actions cannot run it.

README.md:209 and STATUS.md:79 both say the Claude adapter ships.

Work

1. Make engineEnv() and codex.WriteConfig conditional on the selected engine, so a Claude run does not demand credentials it never uses.
2. Decide the Actions story. Installing the Claude CLI in the reusable workflow means an anthropic-api-key secret and an engine input, which is a real addition rather than a docs fix.
3. Until 1 and 2 land, correct the README and STATUS.md to say the adapter exists and is reachable only from a local CLI run.
4. Add the engine option to docs/setup.md when it genuinely works there.

Acceptance

• engine: claude runs with no Azure variables set.
• Either the reusable workflow runs it end to end, or the docs say plainly that it does not.

[charlesgreen]

@simplycubed-code help

[charlesgreen]

Step 3 is done in #97, shipped in v0.1.8. The README no longer says the adapter ships, STATUS.md says Codex on Azure is the engine you can actually run, and both point here.

Steps 1, 2, and 4 are untouched, and they are the ones that make the engine work:

1. engineEnv() and codex.WriteConfig still run unconditionally, so a Claude run demands Azure credentials it never uses.
2. The reusable workflow still installs only the Codex CLI. Running Claude in Actions needs a CLI install, an engine input, and an anthropic-api-key secret.
3. docs/setup.md still offers no engine choice, which stays correct until 1 and 2 land.

Nothing about the adapter itself changed. It remains reachable only from a local CLI run that also has Azure credentials set.