WIP: Surface filter-promoted unraisable warnings directly (#14263)

[paulzuradzki]

Summary

Closes #14263.

filterwarnings = error::ResourceWarning does not fail tests that leak resources through a reference cycle. collect_unraisable wraps the captured warning in PytestUnraisableExceptionWarning, a class the user has not filtered.

collect_unraisable now consults warnings.filters before wrapping. If an active error filter matches the inner warning's class, it raises the original warning. The error::<warning> filter then fails the test.

Scope

The unwrap fires only when an active error filter matches the inner warning's class. A __del__ that raises a Warning without a matching filter still triggers the wrap path. Suites without error::<warning> filters see no change.

Filter matching is approximate: category only, not message/module/lineno. The check errs toward false negatives, never false positives.

Relationship to #14273

#14273 attempted approach 2 from the issue (move GC to pytest_unconfigure). Maintainers closed it unmerged: #13057 (Dec 2024) had already shipped approach 1, so the move-GC change alone produced no observable behavior difference and no fails-then-passes regression test was possible. @Zac-HD asked: "we'd need to see a regression test which demonstrates that the unraisable hook is now subject to warnings."

This branch ships that test by addressing a different symptom: the wrap class hides the user's filter. The third commit lands the move-GC hardening from #14273. That commit is a structural refactor with no observable behavior change today; it decouples the GC step from default_plugins registration order, so the timing invariant no longer depends on LIFO _cleanup_stack ordering. The regression test stays green either way.

Manual testing

Reproducer: my adapted version of the original gist from the issue. The original references an undefined stderr_lines in its run_scenario helper; the adapted version applies a one-line fix.

For a faster check without scaffolding files, write a refcycle-leak test and run pytest -W error::ResourceWarning test_leak.py. The -W flag drives the same code path as the pytest.ini filterwarnings setting.

• Verify the bug on main. Check out main, install (pip install -e .), run the adapted reproducer. Scenario 1 exits 0 (bug confirmed). Scenario 2 exits 1 (the gist's conftest workaround using approach 2 from Session-end gc.collect() in unraisableexception plugin runs after warning filters are torn down, silently losing ResourceWarnings #14263).
• Verify the fix on this branch. Check out this branch, install, run the same reproducer. Scenario 1 now exits 1 with the inner ResourceWarning raised. Scenario 2 still exits 1.
• Verify the scope guard. Run a suite that raises a Warning from __del__ without a matching error filter against this branch. The wrap path still fires; finalizers that pass today keep passing.
• Run a real project that uses error::DeprecationWarning or error::UserWarning filters against this branch. Nothing previously-passing should now fail.

AI usage

Yes. I'm new to repo. Taking some time to review changes more slowly and manually testing for learning.

Changelog

changelog/14263.bugfix.rst.

[FuzzysTodd]

pytest_unconfigure fires before _cleanup_stack.close(), so warning
filters managed via the cleanup stack (the warnings plugin's
catch_warnings context, in particular) are guaranteed active when GC