M1/PR16: performance test infrastructure — BenchmarkDotNet + MemoryDiagnoser baselines #18

Source: maintainer directive + multi-agent review of PR #16 (perf cluster P1-P5 CONFIRMED/PLAUSIBLE), 2026-08-13.

Standing posture (recorded in AGENTS.md): performance is a standing concern in both the SDK and the tooling — SDK targets speed and minimal avoidable allocation, tooling targets speed. No speculative optimization, but obvious waste is always evaluated, starting with low-hanging fruit. Perf claims are settled by benchmarks, not argument.

Deliverable

tests/OpenCode.Sdk.Performance.Tests — BenchmarkDotNet console project (mirrors the BadgeSmith shape: https://github.com/localstack-dotnet/badge-smith/blob/master/tests/BadgeSmith.Api.Performance.Tests/BadgeSmith.Api.Performance.Tests.csproj), riding the repo's full convention set. MemoryDiagnoser on every benchmark — speed and allocation move together.

First benchmark set = the baseline for the confirmed P-findings:

• End-to-end GetMessageAsync via a canned HttpMessageHandler (no network, deterministic bytes) — P1+P2+P3 composite
• Union converter walk over a deep assistant-message fixture — P1 (DOM materialization + second traversal per union level; nested content multiplies)
• Envelope ReadDataPayload parse (ResponseAdapter.cs:52-59) — P2 (full envelope DOM + payload re-traversal)
• Pure Pipeline overhead via GetHealthAsync — P3 (UTF-16 body buffering on success paths)

Rules

• Not a CI gate (shared-runner variance); run manually, wire into the M6 nightly canary lane when it exists. Perf-touching PRs carry before/after numbers.
• ADR-0004 immutable-model allocations and ADR-0007 RawBody retention are contracts, not waste — benchmarks measure around them, never against them.
• Baseline numbers land in this issue when first measured; subsequent optimizations (issue on M3 union redesign) cite them.