test: correct docstring per review measurements; assert exact PARSE_ERROR below 3.14

Review measurements on #3147 (and re-measured here on arm64 macOS) show the
stack-headroom-based recursion guard in the C json scanner starts in CPython
3.14, not 3.12 - on 3.12/3.13 the flip depth is identical across 8/16/64 MB
stacks. Docstring updated accordingly.

The macOS mechanism was also backwards in the old docstring: it is not a
smaller thread stack but a larger one. CPython pins non-main threads to a
16 MiB stack on macOS (THREAD_STACK_SIZE in Python/thread_pthread.h);
measured default-thread flip on arm64 macOS 3.14 is ~149,641 levels -
identical to an explicit 16 MiB stack - so the 100k-deep body parses and
fails validation (INVALID_REQUEST) instead of raising RecursionError.

Since the outcome is deterministic below 3.14, the test now asserts the
exact PARSE_ERROR code there and accepts either rejection only on 3.14+.

Author: Gordon L

tests/server/test_streamable_http_modern.py

@@ -8,6 +8,7 @@
 
 import json
 import logging
+import sys
 from collections.abc import Callable
 from typing import Any
 
@@ -1011,18 +1012,28 @@ async def broken_list(ctx: ServerRequestContext, params: PaginatedRequestParams
 async def test_modern_post_with_deeply_nested_body_is_rejected_not_a_crash() -> None:
     """A deeply nested body is rejected with a 400, never a crash.
 
-    Which JSON-RPC code it gets is platform-dependent: since CPython 3.12 the C
-    json scanner guards recursion by actual C-stack headroom, so depending on
-    the thread's stack size the body either fails to parse (RecursionError ->
-    PARSE_ERROR) or parses into a giant list that then fails request
-    validation (-> INVALID_REQUEST). Both are correct rejections; the
-    deterministic PARSE_ERROR mapping is covered by the monkeypatch test below.
+    Which JSON-RPC code it gets is platform-dependent on CPython 3.14+: the C
+    json scanner there guards recursion by actual C-stack headroom, so whether
+    a 100k-deep body parses depends on the parsing thread's stack size and the
+    per-level cost on that architecture (~112 bytes/level measured on arm64,
+    ~129 on x86_64). It either fails to parse (RecursionError -> PARSE_ERROR)
+    or parses into a giant list that then fails request validation
+    (-> INVALID_REQUEST). CPython gives non-main threads a 16 MiB stack on
+    macOS (THREAD_STACK_SIZE in thread_pthread.h) vs 8-ish MiB defaults
+    elsewhere, which is why macOS parses the body and answers INVALID_REQUEST.
+    Below 3.14 the recursion guard ignores stack size and the 100k-deep body
+    always fails to parse, so the exact PARSE_ERROR code is asserted there.
+    Both codes are correct rejections; the deterministic RecursionError ->
+    PARSE_ERROR mapping is covered by the monkeypatch test below.
     """
     body = b"[" * 100_000 + b"]" * 100_000
     async with _asgi_client(_x_mcp_server()) as http:
         response = await http.post("/mcp", content=body, headers={"content-type": "application/json"})
     assert response.status_code == 400
-    assert response.json()["error"]["code"] in (PARSE_ERROR, INVALID_REQUEST)
+    if sys.version_info >= (3, 14):
+        assert response.json()["error"]["code"] in (PARSE_ERROR, INVALID_REQUEST)
+    else:
+        assert response.json()["error"]["code"] == PARSE_ERROR
 
 
 async def test_modern_post_recursion_error_during_parse_is_parse_error(monkeypatch: pytest.MonkeyPatch) -> None: