Warn when writing or closing a cache file fails

[barveP]

Fixes #15043.

cache.set() already warns when opening a cache file fails, but an OSError from writing or closing it currently escapes. Move the existing write into the same error handler so these failures also produce PytestCacheWarning.

The regression test covers open, write, and close failures. The write and close cases fail before the fix; all three pass afterward. A separate reproduction using a real file-size limit also fails on pytest 9.1.1 and unmodified main, then produces warnings with this fix.

Checks on macOS:

• Full Python 3.13 suite, tox -e py313 -- -q: 4,607 passed, 51 skipped, 15 xfailed, 5 xpassed.
• Cache tests on Python 3.12 and 3.13: 68 passed on each.
• tox -e linting: passed.

JSON serialization and warning filters keep their existing behavior.

Co-developed by Poorva Barve and Codex.

[RonnyPfannschmidt]

Looks good

[RonnyPfannschmidt]

Nitpick we now can use path.write_text

[barveP]

ah yes! switched to path.write_text

[ege-arhan]

Nice consolidation — collapsing the open/write/close paths into a single write_text call inside the existing OSError handler removes the hole where write/close failures escaped as raw tracebacks, and the parametrized test over all three failure modes pins it down well.

Two observations from reading the final state of cacheprovider.py: first, there is now a deliberate asymmetry between get (line ~218, catches OSError and silently returns the default) and set (warns via PytestCacheWarning). That reads correct to me — a cold or unreadable cache should degrade silently, while a failed write means data the user expected to persist is being dropped — but it might be worth one sentence in the set docstring stating the contract explicitly, since a future refactor could easily "harmonize" them in the wrong direction.

Second, on the test itself: it patches Path.open while the implementation calls Path.write_text, which works only because CPython's write_text delegates to open internally. If a future change switched set to os.write on an fd or to atomic write-then-rename, the mocked failure injection would silently stop failing and the test would pass vacuously (warning still raised? no — no exception, no warning, pytest.warns fails, so actually it would catch it). Never mind — pytest.warns as context manager fails the test when no warning fires, so the test is self-guarding. Leaving this note mostly as confirmation the coverage is sound.