fix: normalize API error codes to strings

[Sanjays2402]

• I understand that this repository is auto-generated and my pull request may not be merged

Changes being requested

Normalize non-null API error codes to strings so runtime behavior matches the public str | None annotation. A regression test covers numeric error payloads.

Additional context & links

Closes #3531

[Copilot]

Pull request overview

Normalizes APIError.code to always be a string (when present) so runtime behavior matches the public str | None type annotation and avoids downstream type surprises when servers return numeric error codes.

Changes:

• Coerce non-None error.code values to str during APIError construction.
• Add a regression test covering integer error codes.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/openai/_exceptions.py	Ensures APIError.code is normalized to str when present.
tests/test_client.py	Adds a regression test asserting integer error codes become strings.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[amirhosseinghanipour]

Fix looks correct. Good addition of test covering the exact repro from #3531. LGTM.

[jbeckwith-oai]

Clean at 00e6dafb7c1ff654a2917890f987069dcd82014e. Normalizing a non-null wire value at the APIError construction boundary makes runtime behavior match the public str | None contract without adding downstream branching or indirection, and the regression exercises the reported numeric-code case. I found no correctness or maintainability blockers.

Validation: the focused regression passed; changed-file Ruff lint and format checks passed; targeted Pyright passed; full mypy passed; and git diff --check passed.