Feature: lazy/deferred upstream connection (defer initialize until first tool call) for on-demand credential providers

## Summary

Please add an option (e.g. `--lazy-connect` / `--defer-init`) that defers credential resolution and the signed upstream connection (the remote `initialize` handshake) until the **first tool call**, instead of doing it eagerly at proxy startup.

## Motivation

`mcp-proxy-for-aws` resolves AWS credentials and opens a signed SigV4 connection to the remote endpoint at MCP `initialize` time (i.e. at proxy startup). This breaks environments that provision AWS credentials **on demand, after the MCP session has already started** — "just-in-time" credential vending, where short-lived, least-privilege credentials are written to `AWS_SHARED_CREDENTIALS_FILE` only after the agent explicitly requests them. In these setups there is simply no credential available at process startup.

Observed behavior in such an environment:

- The MCP server starts before any credential has been vended → the proxy's eager `initialize` to the upstream fails immediately.
- The failure surfaces as `JSON-RPC error: -32602: Invalid request parameters("")` (same masking symptom as #304), so the server is marked "failed" for the whole session.
- Other AWS MCP servers that authenticate **lazily** (only at tool-call time) initialize fine in the same environment, because by the time a tool is actually invoked the on-demand provider has already written valid credentials to the shared credentials file.
- With the proxy, there is no second chance: it needed the credentials at startup, which is exactly the moment they don't exist yet.

## Proposed behavior

Any one of the following would resolve it:

1. **`--lazy-connect` / `--defer-init` flag**: complete the local MCP `initialize` immediately (advertise the server as ready), and defer credential resolution + the upstream connection/handshake until the first `tools/list` or `tools/call`.
2. **Retryable startup**: when credentials are unavailable at startup, mark the connection retryable so it re-resolves credentials (fresh `get_credentials()`) on the next request rather than staying permanently failed for the session. (Related to the reconnect-path discussion in #304 and #193/#321.)

## Environment

- mcp-proxy-for-aws 1.6.4
- stdio proxy to `https://eks-mcp.us-west-2.api.aws/mcp` (also reproducible against `https://aws-mcp.us-east-1.api.aws/mcp`, cf. #304)
- Credentials provided via `AWS_SHARED_CREDENTIALS_FILE`, populated on demand *after* the MCP session starts.

## Related

- #304 — same `-32602` surface; error masks the real "no credentials at init" cause
- #193, #321, #388 — credential refresh / reconnect handling

Begin at the MCP initialize handling and the tools/list and tools/call request paths; inspect how get_credentials and the upstream initialize handshake are currently invoked. Compare the lazy-connect and retryable-startup alternatives, then verify that local initialize succeeds without credentials and the first tool request establishes or retries the upstream connection.

Written by the indexing model from the issue text.