fix: avoid importing linopy at pytest config-parse time

The filter ``"ignore::linopy.EvolvingAPIWarning"`` forces pytest to
import ``linopy`` when parsing pyproject.toml to resolve the class
reference.  That eager import loads ``linopy.variables`` from
site-packages — and then ``pytest --doctest-modules linopy`` (used in
the Windows CI job that installs from a built wheel) tries to collect
``linopy/variables.py`` from the source tree, sees the module is
already imported from a different path, and fails every doctest
collection with the "not the same as the test file we want to
collect" error.

Switch to a message-based filter on the builtin FutureWarning:

    "ignore:piecewise:FutureWarning"

Our EvolvingAPIWarning is a FutureWarning subclass with messages that
all start with "piecewise:", so the filter still catches them.
FutureWarning is a builtin so pytest doesn't need to import linopy to
resolve it.  CI collection recovers.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: FBumann

pyproject.toml

@@ -113,7 +113,14 @@ markers = [
 filterwarnings = [
     # Silence our own EvolvingAPIWarning inside the test suite so the
     # piecewise tests don't emit 500+ warnings.  Users still see them.
-    "ignore::linopy.EvolvingAPIWarning",
+    # Match by message prefix on the builtin FutureWarning base class
+    # rather than on ``linopy.EvolvingAPIWarning`` directly — using the
+    # class reference here would force pytest to import linopy at
+    # config-parse time, which loads ``linopy.variables`` from
+    # site-packages and then conflicts with ``--doctest-modules``
+    # collection of ``linopy/variables.py`` in the source tree on
+    # Windows CI.
+    "ignore:piecewise:FutureWarning",
 ]
 
 [tool.coverage.run]