v0.1.68

Protocol translation — 2 of 62 confirmed findings fixed

n accepts semantic 1.0, not just literal "1"

DecodeChatRequest validated the OpenAI n field by comparing raw JSON bytes against the literal string "1". A semantically-identical single-choice request sent as "n":1.0 has wire bytes "1.0", so it was wrongly rejected. Now decodes n to a *float64 and compares the numeric value.

• Test: TestDecodeChatRequestAcceptsFloatOne, TestDecodeChatRequestRejectsNonNumericN (internal/openai)
• Surgical-revert proof: byte-comparison check reinstated → TestDecodeChatRequestAcceptsFloatOne failed ("n:1.0 must pass (semantically n=1), got n is not supported"). Fix restored, test passes.

stream_options.include_usage honored

stream_options was an "owned" wire key (never leaked into Extra), but chatRequestWire had no field to capture it — every streaming client got an unrequested terminal usage chunk regardless of preference. Now threaded through llm.ChatRequest.IncludeStreamUsage into openaiSink, gating the usage chunk; defaults to false when stream_options is omitted, matching OpenAI's documented default. This gateway's own billing (runStream) is unaffected — it captures usage from the upstream call directly, independent of what the sink forwards to the client.

• Test: TestDecodeChatRequestStreamOptions (internal/openai), TestOpenaiSinkSuppressesUsageChunkByDefault, TestOpenaiSinkForwardsUsageChunkWhenRequested (internal/httpapi)
• Surgical-revert proof: decode forced to always return false → TestDecodeChatRequestStreamOptions failed ("IncludeStreamUsage = false, want true"). Fix restored, test passes.

Shipped via #138, chart bump #139.

Next up: finding #3 (Anthropic max_tokens not enforced as required/positive) and #4 (temperature-scale documentation gap), then Admin API's Minor findings.

Full Changelog: v0.1.67...v0.1.68