Tolerate a missing _cloudpickle_submodules key in _function_setstate

[soodoku]

Fixes #593.

_function_setstate pops _cloudpickle_submodules from the slotstate without a default, so a payload that does not carry that key raises KeyError: '_cloudpickle_submodules' from inside pickle.loads, rather than a normal unpickling failure.

This restores handling that used to be there. Before c6f8cd4 the code read:

if '_cloudpickle_submodules' in state:
    state.pop('_cloudpickle_submodules')

That commit ("code clean-up after EOLed Python 3.6 and 3.7") consolidated the module and the surviving version pops unconditionally. Valid cloudpickle payloads always set the key, so this changes nothing for them — it only affects payloads that omit it.

I've deliberately left the issue's CVE framing aside: pickle.loads on untrusted input already permits arbitrary code execution, so I don't think a KeyError there is a security boundary. The narrow case for this change is just that a malformed payload should not crash with an opaque KeyError from the middle of a pop.

If you'd rather have this raise an explicit pickle.UnpicklingError with a clear message than tolerate the omission, that's a one-line change and I'm happy to switch.

Verification

Run against a Python 3.12 venv (dev-requirements.txt pins numpy to python_version <= '3.12', so 3.12 exercises more of the suite than 3.14 would):

• Baseline on unmodified master: 266 passed, 10 skipped, 2 xfailed
• With this change: 267 passed, 10 skipped, 2 xfailed

The only delta is the new test. It fails on master with KeyError: '_cloudpickle_submodules' at cloudpickle/cloudpickle.py:1156 and passes with the fix.

black 25.9.0 (the version pinned in .pre-commit-config.yaml) reports both touched files unchanged. ruff check cloudpickle tests reports the same 81 pre-existing findings before and after, none on the touched lines.

The changelog entry links the issue since the PR number isn't known yet — happy to swap it for the PR link.