fix: propagate HTTP error statuses in API tool

[Piyush0049]

Overview

This PR addresses a logic bug in the api tool where HTTP error responses (4xx and 5xx status codes) were previously swallowed and treated as successful executions. Additionally, it resolves a couple of test suite regressions related to Windows compatibility and unordered slice assertions.

Changes Included

Bug Fixes

• API Tool Error Propagation: Updated pkg/tools/builtin/api/api.go to explicitly check resp.StatusCode. If the status code is >= 400, the tool now properly returns a tools.ResultError containing the status code, the status text, and the truncated response body.
• API Tool Tests: Added TestAPITool_ErrorStatusCode to verify that 500 Internal Server Error responses correctly generate an error result instead of a success object.

Testing and CI Improvements

• Windows Compatibility for Mkfifo: Extracted the TestAgentRefsInDirSkipsNonRegularFiles test (which uses syscall.Mkfifo) out of agent_picker_test.go and into a dedicated agent_picker_unix_test.go file with a //go:build !windows directive. This cleanly resolves cross-platform compilation and test execution issues on Windows.
• Cross-Platform Paths: Updated hardcoded Unix-style paths in agent_picker_test.go to use filepath.FromSlash to ensure the tests pass smoothly on Windows environments.
• Unordered Matching: Switched from assert.Equal to assert.ElementsMatch in sandbox_cmd_test.go for SandboxAllowlist assertions, preventing flaky test failures caused by non-deterministic map or slice ordering.

[aheritier]

🤖 Automated implementer agent — this comment was posted by the implementer bot from Docker Agentic Platform, not by a human developer

The core fix is correct. Returning tools.ResultError (not a Go error) is the right choice — it surfaces the HTTP failure to the LLM with status code, reason phrase, and truncated body so the model can react rather than silently treating an error response as success.

A few observations:

---

• Threshold >= 400 is correct; 3xx redirects are already resolved by Go's HTTP client before this point.
• limitOutput on the error body is appropriate, though the body is already capped at 1 MB by io.LimitReader; the 30 KB limit from limitOutput makes the effective cap 30 KB in both paths — fine.
• http.StatusText for unregistered status codes returns "", producing a slightly odd "status 999 : ..." string. Negligible in practice.

Tests

• TestAPITool_ErrorStatusCode covers the 500 path correctly; a 4xx case (e.g. 401, 404) would round out coverage, but absence isn't a blocker given the code path is identical for all >= 400.

Supporting changes

• Extracting TestAgentRefsInDirSkipsNonRegularFiles to agent_picker_unix_test.go with //go:build !windows is the right approach.
• filepath.FromSlash and assert.ElementsMatch changes are appropriate cross-platform cleanups.

Overall: clean, minimal, correct.