Fix OOB read in getlist() and putdata() when __len__ overstates length

[lazerg]

Fixes #9892.

Changes proposed in this pull request:

• getlist() and _putdata() read the sequence length before calling PySequence_Fast(). A custom sequence whose __len__ reports more items than __getitem__ actually produces makes the later loop read past the materialized list, which segfaults.
• Both functions now take the length from the materialized PySequence_Fast result instead, so they never index past what was actually built.

[akx]

I think the bigger issue is using PySequence_Fast things on custom types where __getitem__ can basically do whatever it likes...

I assume we'd see a similar crash for an object that raises IndexError randomly in __getitem__.

[lazerg]

@akx I tested this directly: a __getitem__ that raises IndexError at random points doesn't crash after this fix.

PySequence_Fast on an object without __iter__ falls back to old-style sequence iteration. That protocol treats IndexError from __getitem__ as the normal end-of-sequence signal, not a propagated exception. It just stops there and materializes whatever came before. test_overstated_length already exercises this, just with a fixed cutoff instead of a random one.

The actual fix in this PR is that n now comes from PySequence_Fast_GET_SIZE(seq) after materialization, not from the caller's declared __len__. So it doesn't matter when IndexError fires. n always matches however many items got materialized. I ran 200 trials with __getitem__ raising IndexError at a 30% chance per index and got no crash or OOB read.

If __getitem__ raises something other than IndexError, CPython propagates it as a real exception from PySequence_Fast, and getlist()/_putdata() already bail out cleanly through if (!seq) return NULL;.

So this looks like the same bug class the PR already fixes, just probabilistic instead of fixed. Keeping this PR scoped to the reported OOB read. If you have a repro that still crashes on this branch, I'd like to see it.