fix: two runtime PEP 604 sites that FA102 structurally cannot catch

3.9 was the last red leg: 1 failed, 8 errors, 1712 passed. Same family as
17e7e6c, but a variant the linter cannot see - both files already carry
`from __future__ import annotations`, which is exactly why FA102 stays quiet
while the code still breaks at runtime.

backend.py `cast(CUDABatchDecoder | None, ...)`. The future import stringifies
annotations; an argument to `cast()` is an ordinary expression and is evaluated
on import, so `type.__or__` is reached on 3.9 and the package fails to import.
Quote the target - `cast` never evaluates its first argument, and type checkers
read string forward refs fine.

rest_api.py `n_qubits: int | None` on a pydantic BaseModel. Here the future
import actively hurts: the annotation arrives at pydantic as the string
"int | None", which it eval()s to resolve the model, and on 3.9 that raises.
It surfaced as six errors recommending `eval_type_backport`, plus two cascading
'NoneType' has no attribute '_rate_lock' errors once the module failed to load.
Use `Optional[int]`. The neighbouring `list[list[int]]` is left alone - PEP 585
builtin subscripting landed in 3.9; only PEP 604 unions did not.

Swept for the rest of this shape rather than fixing only what failed: these are
the only two `cast()` sites and the only pydantic field affected; no
isinstance/issubclass union arguments exist.

The real guard is the 3.9 leg itself, which now gets far enough to import every
module - it could not before 17e7e6c.

Author: qectorlab

python/qector_decoder_v3/backend.py

@@ -295,11 +295,19 @@ def _get_cpu_single(self) -> FastUnionFindDecoder:
     def _get_cpu_rayon(self) -> BatchDecoder:
         return cast(BatchDecoder, self._get_decoder(Backend.CPU_RAYON))
 
+    # The cast targets are quoted deliberately. `from __future__ import
+    # annotations` stringifies *annotations*, but an argument to `cast()` is an
+    # ordinary runtime expression, so a bare `X | None` here is evaluated on
+    # import and raises TypeError on 3.9, where `type.__or__` does not exist.
+    # `requires-python` is >=3.9, and this made the whole package unimportable
+    # there. ruff's FA102 cannot see it precisely because the file already has
+    # the future import. `cast` never evaluates its first argument, so a string
+    # is both correct at runtime and understood by type checkers.
     def _get_cuda(self) -> CUDABatchDecoder | None:
-        return cast(CUDABatchDecoder | None, self._get_decoder(Backend.CUDA))
+        return cast("CUDABatchDecoder | None", self._get_decoder(Backend.CUDA))
 
     def _get_opencl(self) -> OpenCLBatchDecoder | None:
-        return cast(OpenCLBatchDecoder | None, self._get_decoder(Backend.OPENCL))
+        return cast("OpenCLBatchDecoder | None", self._get_decoder(Backend.OPENCL))
 
     # -- native auto decoder ------------------------------------------------
     def _try_native_auto(self, syndromes: np.ndarray) -> np.ndarray | None:

python/qector_decoder_v3/rest_api.py

@@ -35,7 +35,7 @@
 import logging
 import time
 import uuid
-from typing import Any
+from typing import Any, Optional
 
 import numpy as np
 
@@ -123,7 +123,14 @@ def _rate_limit_allow(client_ip: str) -> bool:
     class DecodeRequest(BaseModel):
         check_to_qubits: list[list[int]]
         syndrome: list[int]
-        n_qubits: int | None = None
+        # `Optional[int]`, not `int | None`. Pydantic resolves model annotations
+        # at runtime with `get_type_hints`, and `from __future__ import
+        # annotations` only makes that worse here: the annotation reaches
+        # pydantic as the *string* "int | None", which it then eval()s, and on
+        # 3.9 that raises. It surfaced as six errors telling us to install
+        # `eval_type_backport`. `list[list[int]]` above is fine — PEP 585
+        # builtin subscripting landed in 3.9; only PEP 604 unions did not.
+        n_qubits: Optional[int] = None
         use_batch: bool = False
 
     class DecodeResponse(BaseModel):