fix(client): typed multi-response handling with ApiError envelope (closes #8)

Operations that declared multiple responses (e.g. 200 + 400) silently
collapsed into a single Response type — the inline-naming function in
analysis.rs ignored its status_code argument so the second schema
overwrote the first in the schema registry. The generated client then
tried to deserialize success bodies into the error shape.

Fix the naming collision and reshape the error story:

- ApiError<E> envelope always carries status + headers + raw body, so
  callers can inspect what the server actually sent without hacking the
  generated code (the original side-tangent in #8).
- ApiOpError<E> = Transport(HttpError) | Api(ApiError<E>) is the new
  return type for every generated operation method.
- Per-operation error enums are emitted when an operation declares
  non-2xx body schemas; otherwise ApiOpError<serde_json::Value> falls
  back so the body is still inspectable as JSON.
- Response handler reads the body to a string before any typed parse,
  so deserialization failures preserve the bytes.

Breaking: generated method signatures change from HttpResult<T> to
Result<T, ApiOpError<E>>. The HttpError::Http variant and from_status
helper are removed from generated code (replaced by ApiError<E>). Bump
to 0.2.0 per CLAUDE.md "no backwards compat" policy.

End-to-end compile tests cover the toy multi-response spec plus the
anthropic and openai fixtures so the new shape is exercised against
realistic schemas, not just string-search assertions.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: lightsofapollo

Cargo.lock

@@ -1,6 +1,6 @@
 [package]
 name = "openapi-to-rust"
-version = "0.1.15"
+version = "0.2.0"
 edition = "2024"
 rust-version = "1.85.0"
 authors = ["James Lal"]