mcp(fix[deps]): bump fastmcp>=3.2.4 to activate ReadonlyRetryMiddleware

The shipped ``ReadonlyRetryMiddleware`` (commit ``bd37f29``) is a
production no-op under fastmcp 3.2.3:

- ``RetryMiddleware._should_retry`` only checks ``isinstance(error,
  retry_exceptions)`` — does NOT walk ``__cause__``.
- ``handle_tool_errors_async`` (``_utils.py:842-850``) wraps every
  ``LibTmuxException`` as ``ToolError(...) from LibTmuxException``.
- At the middleware layer the exception type is ``ToolError``, not
  ``LibTmuxException``, so ``_should_retry`` returns ``False`` and
  the retry never fires in production.

The shipped tests in ``tests/test_middleware.py:475+`` only pass
because ``_FlakyCallNext`` raises ``LibTmuxException`` directly,
bypassing the production decorator wrap path.

fastmcp v3.2.4 commit ``031c7e03`` (PR #3858 "Fix RetryMiddleware
not retrying tool errors") adds the ``__cause__`` walk to
``_should_retry``. Reproduced the production-flow bug under 3.2.3
with a 25-line harness (calls=1) and verified the fix on 3.2.4
(calls=2 with max_retries=1).

Free win that ships in the same bump: PR #3872 (commit
``f3c00ba1`` "Extract parameter descriptions from docstrings")
adds an automatic NumPy/Google/Sphinx docstring parser that
populates per-parameter ``inputSchema.description`` fields. The
project's tools already use NumPy ``Parameters\n----`` style
throughout (verified ``wait.py``, ``_utils.py``, ``middleware.py``),
so per-parameter descriptions become visible to LLM clients with
zero code changes.

Next commit adds an integration-style regression test that calls a
real ``@handle_tool_errors``-decorated tool through the middleware
stack — catches the production no-op AND any future regression
where someone changes the decorator's exception wrapping.

Author: tony

pyproject.toml

@@ -41,7 +41,7 @@ include = [
 
 dependencies = [
   "libtmux>=0.55.0,<1.0",
-  "fastmcp>=3.1.0,<4.0.0",
+  "fastmcp>=3.2.4,<4.0.0",
 ]
 
 [project.urls]