fix(pilot): kiota client must send uncompressed JSON request bodies

[ShocOne]

What happened

The first live run of the new go | Acceptance tests (kiota) pipeline failed on its very first create: thousandeyes_tag → bare 400 Bad Request, no detail.

Diagnosis (fully offline)

• The serialized body is byte-for-byte identical to the create body the recorded probe evidence shows the API accepting ({"accessType","key","objectType","value"}) — the body was not the problem.
• Capturing the client's actual wire request against a local stub showed the real cause: kiota-http-go's default middleware gzips every request body (Content-Encoding: gzip), and the ThousandEyes API refuses compressed bodies with a bare 400. The resty pilot — and every committed recording — has always spoken plain JSON.
• The 400 carried no explanation because the OpenAPI spec declares no response body for POST /tags 400, so kiota generates no error mapping for it — a spec gap, not a client bug.

Fix

internal/client builds its adapter with the default middleware set minus request compression (GetDefaultMiddlewaresWithOptions(NewCompressionOptionsReference(false))), with a comment recording why this is load-bearing. A new wire regression test (TestUnit_Client_SendsPlainJSONBodies) pins the contract against a capture server — method, path, bearer header, Content-Type: application/json, no Content-Encoding, and the exact JSON fields — so the compression middleware returning fails a unit test instead of a live tenant run.

Verification

• The capture test shows the exact previously-gzipped body now going out as plain JSON matching the recorded accepted shape.
• Pilot module builds and all tests green.
• Re-dispatch go | Acceptance tests (kiota) after merge to confirm against the live tenant.

🤖 Generated with Claude Code