Follow-up to #403 / #405.

Gap

The interactive mm init wizard checks a precondition before warning the user for ONNX (fastembed import), Ollama (_ollama_available binary + _have_module("ollama") Python client, after #405), and kiwipiepy (import check). The OpenAI path, by contrast, skips the Python-client check entirely — it only validates the API key via _test_openai_key (a network call).

# init_cmd.py ~line 354
elif choice == 4:
    provider = "openai"
    ...
    api_key = nav_prompt("  OpenAI API key", hide_input=True)
    if _test_openai_key(api_key):
        click.secho("  API key is valid.", fg="green")
    else:
        click.secho("  API key test failed. ...", fg="red")

Meanwhile the -y extras gate does check _have_module("openai") (see _collect_missing_extras). So:

• Wizard + no openai package + valid key → silent pass (config saved, runtime falls back later or errors opaquely).
• -y --provider openai + no openai package → refuses upfront.

The wizard's _y_refuse_hint() bridge from #405 doesn't help here because there's no fallback site to attach it to.

Suggested fix

Add a _have_module("openai") check in the wizard's OpenAI branch before the API-key prompt. If missing:

1. Warn (" openai Python client not installed.").
2. Print the install hint (_extra_install_hint(['openai'], state)).
3. Call _y_refuse_hint("--provider openai", "openai") and add "openai" to state["_extras_warned_inline"] (mirrors Ollama fix(init): wizard fallback mentions -y refuse semantic (closes #403) #405).
4. Still prompt for the key and save intent — same warn-and-save semantics as Ollama/ONNX.

This closes the last asymmetry between the wizard and the -y gate for the four provider/tokenizer axes (onnx / ollama / openai / kiwipiepy).

Not a blocker for #405

#405 explicitly scoped this out (one change per PR; #403's scope was only the three paths that already had a check). Opening this issue so the OpenAI axis doesn't fall off the radar.