Memory allocated when creating Python objects is never automatically freed

**Affects:** PythonCall

**Describe the bug**
I am trying to use PythonCall.jl to call the Python interface to CP-SAT, which is a popular constraint programming library from Google's OR-Tools toolkit. The problem is that the memory that gets allocated when creating a Python object from that interface is never automatically freed.

A function ```createmodel()``` is used to create a ```CpModel``` object`, which goes out of scope after the function terminates. Each time the function is executed, the memory gets fuller, until eventually the Julia process gets killed. The expected behavior is that at some point before Julia gets killed, the memory that was allocated for objects that are out of scope should get released.

Here are the steps to reproduce a MWE, assuming the environment already has PythonCall.jl and CondaPkg.jl:

Add OR-Tools to the environment and import it:
```julia
using PythonCall, CondaPkg
] conda pip_add ortools
cp_model = pyimport("ortools.sat.python.cp_model")
```

Define the function that will create and initialize a ```CpModel``` object:
```julia
createmodel() = let
model = cp_model.CpModel() # create model
variables = [model.new_int_var(0,1, "x_" * string(i)) for i in 1:100] # add variables to the model
model.add_allowed_assignments(variables, [rand(0:1, 100) for _ in 1:200000]) # add constraints over those variables
return nothing
end
```

Repeatedly call ```createmodel()``` and observe that the memory usage keeps going up until the Julia process gets killed.
```julia
createmodel()
createmodel()
createmodel()
# ... if you keep calling createmodel(), eventually the memory gets full
```

**Your system**
Please provide detailed information about your system:
- Operating System: Fedora Linux 43
- Python version: 3.14.3
- ```julia
versioninfo()
```
```
Julia Version 1.12.3
Commit 966d0af0fdf (2025-12-15 11:20 UTC)
Build Info:
Official https://julialang.org release
Platform Info:
OS: Linux (x86_64-linux-gnu)
CPU: 8 × 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
WORD_SIZE: 64
LLVM: libLLVM-18.1.7 (ORCJIT, tigerlake)
GC: Built with stock GC
Threads: 1 default, 1 interactive, 1 GC (on 8 virtual cores)
```

- ```julia
import Pkg; Pkg.status()
```
```
Status `~/MWECPSAT/Project.toml`
[992eb4ea] CondaPkg v0.2.34
[6099a3de] PythonCall v0.9.31
```

- ```julia
import CondaPkg; CondaPkg.status()
```
```
Environment
/home/dmaioli/MWECPSAT/.CondaPkg/.pixi/envs/default
Pip Packages
ortools v9.15.6755
```

**Additional context**
- Calling ```PythonCall.pydel!(model)``` and/or ```for v in variables PythonCall.pydel!(v) end``` inside the body of the function does not have any visible effect
- Executing ```GC.gc()``` after the function calls has the effect that at least part of the allocated memory gets freed, but sometimes this does not happen if it is executed only once.
- Calling the equivalent code directly from Python works as expected, i.e. the memory gets freed after the function terminates. Here is the Python version:
```python
from ortools.sat.python import cp_model
import random
```
```python
def createmodel():
model = cp_model.CpModel()
variables = [model.new_int_var(0,1, f"x_{i}") for i in range(100)]
model.add_allowed_assignments(variables, [[random.randint(0,1) for _ in range(100)] for _ in range(200000)])
return None
```
```python
createmodel()
createmodel()
createmodel()
# ... if you keep calling createmodel(), the memory never gets full
```

Start by running the provided createmodel() CP-SAT MWE with PythonCall and CondaPkg, then compare the effects of PythonCall.pydel!(...) and GC.gc(). Trace PythonCall's object-lifetime and garbage-collection entry points; done means repeated calls release out-of-scope allocations without requiring manual GC.

索引モデルが issue の本文から書いたものです。