fix: read scientific notation in run_end_ceiling_ms as the CLI does

[NovaCode37]

Fixes #1359

run_end_ceiling_ms() documents that it reads CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS "as the CLI will see it", but it parsed the value with int(), so 1e6 was rejected and silently fell back to the 10 minute default. The SDK then closed stdin on a different schedule than the caller configured.

This takes option 1 from the issue: a plain integer is still parsed with int(), so a very large value keeps the exact precision a float round-trip would cost it, and only when that fails does the value go through float() to pick up the integral scientific notation the CLI reads.

1e6  -> 1000000
1e2  -> 100

A value that is not finite or not integral is rejected rather than truncated. That is deliberate: truncating would turn 0.5 into 0, and 0 is the spelling that means "no limit", so a user asking for a sub-millisecond ceiling would get an unbounded one instead.

Behavior kept as it was: unset and empty fall back to the default, 0 still means no limit, whitespace around a plain integer is still accepted, invalid and negative values still fall back to the default, and a huge integer string is still honored exactly and clamped later by the sleeper.

Tests

Added nine cases to TestRunEndCeilingFromEnv.test_parse, covering 1e6 and 1e2 from the issue, uppercase 1E3 with whitespace, scientific notation coming from the ambient environment, and the rejections (-1e6, 1.5, 0.5, inf, nan), plus a 25-digit integer to pin the exactness.

pytest tests/test_query.py passes (103 tests), and ruff and mypy are clean.

[sigley]

Validated exact head eaf417f against the issue acceptance boundary. Integral scientific notation now parses as intended (including 1e6 and 1e2), 0e19 preserves the zero/no-limit semantics, fractional and non-finite spellings are rejected, and very large plain integer strings keep exact precision. The branch merges cleanly with current main; tests/test_query.py passes 103/103 and compile/diff checks are clean. I do not see a blocking correctness issue in this approach.