fix(apicompat): scope additional tools parsing

[wp-a]

Summary

Restrict tools decoding in Responses input items to objects whose type is actually additional_tools.

Problem

EffectiveResponsesTools scans the Responses input array for Codex additional_tools items. A normal message object can legally contain unrelated extension fields. If such an object contains a non-array field named tools, the current scanner tries to decode it as []ResponsesTool before checking the item type and rejects the entire request.

Root cause

Each object was decoded into a combined {type, tools} structure in one pass. JSON decoding therefore validated the shape of tools even for objects that were not additional_tools items.

Fix

• Decode only the type discriminator first.
• Skip non-additional_tools objects before touching their tools field.
• Decode and validate tools only for actual additional_tools items.

Malformed tools on a real additional_tools item still returns the existing contextual error. No request conversion refactor is included.

Verification

• Confirmed the non-target-item regression test fails on the base revision with cannot unmarshal string into ... []apicompat.ResponsesTool.
• Added the complementary assertion that malformed actual additional_tools items are still rejected.
• go test ./internal/pkg/apicompat -run 'TestEffectiveResponsesTools_(IgnoresMalformedToolsOnNonAdditionalItem|RejectsMalformedAdditionalTools)' -count=1
• go test ./internal/pkg/apicompat -count=1
• go test ./... -count=1
• go vet ./...
• git diff --check upstream/main..HEAD