fix: prevent credential_process hang on Windows in stdio transport mode

[rshevchuk-git]

Summary

• Monkey-patches botocore's ProcessProvider._retrieve_credentials_using to pass stdin=subprocess.DEVNULL when spawning credential_process subprocesses
• Prevents the child process from inheriting the MCP JSON-RPC pipe as its stdin, which causes Popen.communicate() to hang indefinitely on Windows (IOCP)
• Adds comprehensive stress tests validating the fix across concurrent calls, pipe inheritance, and end-to-end credential resolution

Problem

When mcp-proxy-for-aws runs in stdio transport mode, its stdin is the MCP JSON-RPC pipe. Botocore's ProcessProvider spawns credential_process subprocesses without specifying stdin, so the child inherits the pipe. On Windows this causes the subprocess to hang indefinitely because it holds an open handle to the pipe, blocking Popen.communicate() from completing.

This affects any user with credential_process in their AWS profile (e.g., isengardcli credentials) when using the MCP proxy on Windows through IDE integrations (Kiro, Cline, Claude Code).

Fixes D454977820

Test plan

• 12 new unit tests covering:
  • Patch is active (stdin=DEVNULL present in source)
  • Pipe inheritance behavior with/without fix
  • Error handling preserved (failed process, invalid version)
  • Concurrent credential_process calls with active MCP pipe (10 threads)
  • End-to-end boto3 session with credential_process + simulated MCP pipe
• All 192 existing unit tests pass
• Verified RefreshableCredentials (expiring creds) path works
• Verified static credentials profiles are unaffected
• Verified failed credential_process error propagation works