Add object tracking functionality for Python 3.13.3+

[pablogsal]

This commit adds support for tracking Python objects that survive test execution
using the new reference tracking API introduced in memray (commit e567c3cf).

Issue number of the reported bug or feature request: #

Describe your changes
A clear and concise description of the changes you have made.

Testing performed
Describe the testing you have performed to ensure that the bug has been addressed, or that the new feature works as planned.

Additional context
Add any other context about your contribution here.

[godlygeek]

@pablogsal ping (note that this will need to be rebased in order for tests to pass)

[pablogsal]

@godlygeek I think I addressed everything. Ready for another round

[godlygeek]

@pablogsal OK, the ball is back in your court. Take a look at my fixup commits and see if there's anything you're not happy with.

I figured out what was going on with the frame showing up as leaked - we were seeing our own call to contextlib.contextmanager.__exit__ for when we resumed our generator to stop the tracking. I've worked around that by pushing the tracking disablement up one layer, into our wrapper functions. It's a bit ugly, since it adds some duplication, but it fixes the problem.

I've also added a bit of documentation, and cleaned a few small things up.

I think we probably need to add a filter_fn argument to this marker, like the one that limit_leaks takes, so that people can ignore known leaks due to caches or the like. Do you agree?

[godlygeek]

I've pushed another commit that adds filtering.

One last thing I'm not totally happy with here: I don't like the marker name. track_leaked_objects doesn't make it obvious the test will fail if there are any leaked objects. Maybe we should call it limit_leaked_objects for consistency with limit_memory and limit_leaks? Or ensure_no_leaked_objects maybe...

[pablogsal]

Hey @godlygeek ,

I pushed 8 fixups that autosquash into your two commits. Nothing structural, mostly tightening things up, but there were a couple of real bugs worth calling out.

The big one: the Manager was holding onto every "leaked" object for the entire run. It did a .get on the surviving-objects dict and never cleared the entry, so the leak detector was itself leaking, and worse, those objects (and everything they referenced) stayed alive through all the later tests, which could quietly skew their results. Changed it to .pop so the objects get released once the report's built.

Second real one: the Python 3.13.3+ guard was raising inside the pytest_pyfunc_call hookwrapper. That fires during the call phase and raises before the yield, which breaks the wrapper protocol, so on an old interpreter you'd get an ugly internal error mid-run instead of the clean failure the docs promise. Moved it into pytest_collection_modifyitems raising UsageError, so now it fails at collection like it's supposed to.

The rest is just small stuff. Smoke-tested every path on 3.14.5 with memray 1.19.2, basic leak/no-leak, the filter, the report overflow, repr failures, async, and the version guard. All good shit.

[godlygeek]

All of your changes LGTM. Thoughts on the marker name? @pytest.mark.track_leaked_objects doesn't imply anything about the test failing if there are leaks. I propose changing it to limit_leaked_objects - any objections?

[pablogsal]

No, I think that's a good name will make the change and land

[godlygeek]

Approved, pending that rename