sdk(0.1.4): accept bare cm_<id> in chat.completions, drop qualified_name

[kunwar-vp]

Why

We were making customers address the same custom model two different ways:

client.custom_models.get(model.id)               # cm_abc123
client.chat.completions.create(model=model.qualified_name)  # custom:cm_abc123

The custom: prefix is a wire-level routing detail of the model gateway — it shouldn't have leaked into the public API surface.

What

Collapse both paths to model.id. Resolved entirely inside the SDK — no backend change, no protocol change, no latency hit (the wire request is byte-identical to the prefixed form).

• chat.completions.create (sync + async) normalizes the model param: bare cm_<hex> ids get the gateway's custom: prefix prepended before delegating to the openai client.
• Pre-prefixed strings (custom:cm_...) and first-party catalog ids (meta-llama/..., Qwen/...) pass through unchanged. Old code keeps working.
• Auto-wake's _extract_custom_model_id is unchanged in behavior — it sees the post-normalization value, so cold-start retry continues to fire on bare-cm calls.
• CustomModel.qualified_name property removed. Migration is model.qualified_name → model.id; the rare caller who needs the wire-level form can write f"custom:{model.id}".

Versioning — 0.1.4 (patch)

Pre-1.0, and qualified_name (a) was undocumented outside one example block, (b) shipped two weeks ago in 0.1.0, (c) is being removed because the surface that justified its existence (passing it to chat) is now redundant. The new normalization on the input side is purely additive. If anyone hits this in the wild we'll restore qualified_name as a deprecated alias.

Docs

README.md, docs/cold-starts.md, scripts/e2e.py, and every example under examples/ updated to use model.id consistently. examples/openai_compat.py deliberately keeps custom:cm_... because that example is about bypassing graphn.Client — it's now annotated to make that contrast explicit.

Companion docs PR for the BYOM tutorial on agent-foundry: voltagepark/agent-foundry#818.

Test plan

• ruff check src tests clean.
• pytest -ra — 43/43 pass.
• New test_chat_normalizes_model_param_for_each_namespace parametrized test covers bare cm, prefixed cm, HuggingFace-style, and non-string inputs.
• test_chat_auto_wakes_cold_custom_model_and_retries now feeds the bare id and asserts the prefixed form goes out on the wire.
• End-to-end against beta gateway: bare cm_<id> import → wait_until_ready → chat completion (cold-start auto-wake exercised).
• CI green on Py 3.10/3.11/3.12/3.13.
• After merge: auto-tag job creates v0.1.4, build + publish ship to PyPI in the same workflow run, pip install graphn==0.1.4 works ~1 min later.

[kunwar-vp]

Pre-merge e2e against beta — passed

Ran a focused live test against cp-beta.graphn.ai / model-beta.graphn.ai with the local branch installed. Targeted an existing ready custom model in the workspace and exercised the four interesting paths:

target: id='cm_e261ebeef742' name='qwen3-0.6b'

[1] CustomModel.qualified_name should NOT exist
  ok — AttributeError: 'CustomModel' object has no attribute 'qualified_name'

[2/3] chat.completions.create with bare id, capturing wire payload
  ok — chat returned: '<think>\nOkay, the user wants me'
  wire model field: 'custom:cm_e261ebeef742'
  ok — SDK normalized 'cm_e261ebeef742' -> 'custom:cm_e261ebeef742' on the wire

[4] streaming with bare id
  ok — 20 deltas: '<think>\nOkay, the user is asking me to count: 1, 2, 3'

ALL CHECKS PASSED

The wire-payload check used a one-off httpx send spy on c.chat.openai_client._client to capture the actual outgoing JSON body. Confirmed the SDK rewrites cm_e261ebeef742 -> custom:cm_e261ebeef742 at the boundary, so the gateway sees byte-identical traffic to the old prefixed form.

Auto-wake (cold-start retry) was not exercised live because both models in the workspace were warm. That path is untouched by this PR — it consumes the post-normalization model string via _extract_custom_model_id, and the wire-payload check above proves the normalized string is what reaches the openai delegate.