Update `cloudpickle` dependency to allow 3.1.2

Start at setup.py line 28 and confirm the current cloudpickle constraint. Check dependency resolution with DSPy and Streamlit[snowflake], then validate UDF and stored-procedure registration; done when cloudpickle 3.1.2 is admitted without breaking the stated compatibility constraint.

What is the current behavior?

setup.py constrains cloudpickle with an exact upper bound at 3.1.1 (link).

cloudpickle 3.1.2 was released 2025-11-03 and is currently the latest release, so the ceiling excludes it.

What is the desired behavior?

Raise the upper bound to admit cloudpickle 3.1.2, i.e. cloudpickle>=1.6.0,<=3.1.2,!=2.1.0,!=2.2.0.

How would this improve snowflake-snowpark-python?

The ceiling currently makes Snowpark uninstallable alongside DSPy, which has required cloudpickle>=3.1.2 since 3.2.0 (the latest release is 3.3.1) (link).

The two floors and ceilings are one patch version apart and cannot be satisfied together. This is reachable without depending on Snowpark directly, because streamlit[snowflake] pulls in snowflake-snowpark-python[modin]:

$ uv pip compile requirements.in
  × No solution found when resolving dependencies:
  ╰─▶ Because snowflake-snowpark-python>=1.53.1 depends on cloudpickle>2.2.0,<=3.1.1
      and streamlit[snowflake]==1.52.2 depends on
      snowflake-snowpark-python[modin]>=1.17.0, we can conclude that
      dspy==3.3.1 and streamlit[snowflake]==1.52.2 are incompatible.

So any project that both serves a Streamlit app against Snowflake and uses DSPy has to pick one. The practical workarounds are all unattractive: pin DSPy to 3.1.3 and forgo ~two minor releases, split the project into two environments, or override the constraint and lose the guarantee it encodes.

cloudpickle 3.1.2 is a single-fix release:

Fix pickling of abstract base classes containing type annotations for Python 3.14" (cloudpipe/cloudpickle#578)

with no change to the pickle format or public API, so the compatibility risk relative to 3.1.1 looks small.

I'm happy to test a candidate build against UDF and stored-procedure registration if that would help.