time: test_get_current_time_errors fails on macOS (case-insensitive tz database)

Finding: In modelcontextprotocol/servers, the src/time test test_get_current_time_errors (case arguments5, timezone "europe/warsaw") is reported to fail on macOS while passing on Linux CI, because the lowercase key resolves there and the server returns a successful result instead of an error (https://github.com/modelcontextprotocol/servers/issues/5060). The reporter says it happens on v2/main and on the SDK v2 port branch for #4851, so it appears independent of the SDK version. No specific package version is stated. Reported mechanism: ZoneInfo reads the system tz database from /usr/share/zoneinfo, which the reporter says is on a case-insensitive APFS volume, so the lowercase key maps to Europe/Warsaw. The expected error text on Linux is a no-time-zone-found message for that key. The consequence reported is that npm run local:gate cannot exit 0 on macOS. The reporter's reproduction is to run, from src/time, a frozen uv sync with all extras and dev, then pytest on tests/test_protocol.py filtered by test_get_current_time_errors, which gives one failure (arguments5) (issue body). A commenter says they verified the behavior across platforms and attributes it to the same filesystem case-insensitivity (https://github.com/modelcontextprotocol/servers/issues/5060#issuecomment-6068345958). They propose that get_zoneinfo() call ZoneInfo first, then reject any key not present in zoneinfo.available_timezones() by raising ZoneInfoNotFoundError, with the same check for --local-timezone validation in serve(). They say this keeps ValueError handling for relative and absolute paths. They claim a fork commit (400ffd5) with a unit test, 56 passing tests, 96% coverage and clean ruff. These are self-reported and unreviewed. Status: the issue is closed, but the supplied head/tail timeline shows no maintainer statement, merged pull request, or release. The closure reason is not shown, and middle comments may be omitted, so a resolution may exist upstream. When filed, the reporter framed the expected outcome as a behavior choice: make the server reject non-exact IANA keys on every platform, or make the test expectation conditional on a case-sensitive filesystem. Whether that choice was settled after closure is unknown. Closure is not evidence of a fix. Limitation: this is an external report plus a community-proposed patch. It was not reproduced by KFA, and the proposal was not verified. The test may still differ on macOS; the closure reason and any resolution are not shown in the supplied timeline, so check the upstream repository for the actual outcome.