[#397 audit follow-ups] LOW: batch-input embeddings e2e + null-embedding hardening

Context

PR #397 audit raised two LOW findings, filed here as follow-ups so they don't block merge:

1. No multi-input (batch) e2e coverage on the embeddings round-trip

PR #397 covers data.length === 1 only. The wire-layer enum doesn't care about batch size (the surrounding Vec<OpenAiEmbeddingObject> already deserializes any-length arrays), but a regression that mangled the data[1+] indices on the way back would only be caught by a batch case.

Fix: add a 4th subtest in tests/e2e/src/cases/openai-embeddings-base64-e2e.test.ts:

• Request input: ["hello", "world"]
• Mock upstream returns 2 base64 entries
• Assert data.length === 2 and both embedding fields are strings

2. null embedding field still rejected

Pre-PR: embedding: Vec<f32> rejected null. Post-PR: embedding: EmbeddingVector (untagged enum over Vec<f32> and String) still rejects null — serde_json::from_str::<EmbeddingVector>("null") returns Err.

An out-of-spec upstream that emitted {"embedding": null} would still 502. Pre-PR did the same so this isn't a regression, but it's a wire-shape hardening opportunity.

Fix options:

• Add Option<EmbeddingVector> wrapper at EmbeddingObject.embedding so null deserializes to None. Surface to the SDK as null per JSON pass-through.
• OR: explicit Null variant on EmbeddingVector.

Either preserves pass-through semantics. The first is less invasive.

Tracking

• Parent: PR #397, issue #393.
• Severity: LOW (both are hardening, not customer-blockers).

Start with tests/e2e/src/cases/openai-embeddings-base64-e2e.test.ts and the EmbeddingObject/EmbeddingVector deserialization definitions. Add the two-input round-trip coverage, then verify null embedding values deserialize without a 502 while preserving JSON pass-through. Done means the batch assertions pass and the null case is covered by an appropriate test.