Support Python3.14

[glatterf42]

This PR aims to add support for Python 3.14. Since this already works in genno, we might also manage here already :)

In its structure, the PR is analogous to #132. Though when I ran poetry check to confirm the lock file was up to date with pyproject.toml, I received numerous DeprecationWarnings about poetry 2.0 having moved from the tool.poetry section to the standard project (see their docs for more details). Thus I took this opportunity to perform the migration, too.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.3%. Comparing base (488ec2a) to head (b711f72).

Additional details and impacted files

@@           Coverage Diff           @@
##            main    #209     +/-   ##
=======================================
- Coverage   93.3%   93.3%   -0.1%     
=======================================
  Files        256     256             
  Lines      10918   10932     +14     
=======================================
+ Hits       10193   10200      +7     
- Misses       725     732      +7     

Files with missing lines	Coverage Δ
ixmp4/core/iamc/data.py	100.0% <100.0%> (ø)
ixmp4/core/run.py	100.0% <100.0%> (ø)
ixmp4/data/api/base.py	88.5% <100.0%> (+<0.1%)	⬆️
ixmp4/data/auth/context.py	95.3% <100.0%> (ø)
ixmp4/data/db/base.py	92.3% <100.0%> (-0.1%)	⬇️
ixmp4/data/db/iamc/datapoint/repository.py	98.1% <100.0%> (ø)
ixmp4/data/db/iamc/timeseries/repository.py	92.2% <100.0%> (ø)
ixmp4/data/db/meta/repository.py	97.8% <100.0%> (ø)
ixmp4/data/db/model/filter.py	86.0% <100.0%> (ø)
ixmp4/data/db/scenario/filter.py	67.4% <100.0%> (ø)
... and 2 more

... and 2 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[glatterf42]

Not sure how we want to handle this. It's mainly here to show that everything works now. I've asked the pandera maintainers if they have an ETA for a next release, but no reply so far. We can merge like this and keep it in mind (our dependencies already allow the next pandera release whenever it drops) for potential issues being opened, or we wait until we have the release and merge after dropping the "TEMPORARY" commit.

[glatterf42]

I'm not sure why we had this construct of setting columns to themselves as different types, and it might not matter anyway with the big rewrite, but I found this erroneous: in some iamc tests ("test_run_datapoints_raw" or so), this function would receive a step_datetime columns of datetime64[ns] type, but find a dtype of object stored for it in self.dtypes, effectively replacing the correct type with a generic one.
This solution uses hardcoded names, which is not ideal either, but keeps the dtype correct.

Though it does retain the ChainedAssignmentError warning that it was supposed to address: the CI at least still shows this warning for line 145, but even though I use the same versions of pandas and pydantic locally, I can't replicate this (I do use Python 3.12 locally, not 3.14).
Using df.loc[:, name] = pd.to_datetime(df.loc[:, name]) does not resolve this warning, unfortunately.
But maybe the rewrite doesn't rely so much on these exact forms of assignment :)