gh-151403: Fix use-after-free when an argv item's __fspath__ mutates args

[tonghuaroot]

_posixsubprocess.fork_exec() converts each args item with
PyUnicode_FSConverter(), which runs the item's __fspath__(). The item is only
borrowed from the (incref'd) args sequence. If __fspath__() drops the
sequence's last reference to the item and then returns a non-str/bytes
object, the error path in PyOS_FSPath() reads Py_TYPE() of the now-freed item
— a use-after-free.

It is reachable from subprocess.Popen when a later argv item is a PathLike
whose __fspath__() mutates the args list, e.g.
subprocess.Popen(["/bin/true", Evil()]).

The between-iteration length recheck only catches a shrink between iterations;
the free here happens inside the current iteration's PyUnicode_FSConverter()
call. The fix keeps the borrowed item alive with an Py_INCREF across the
conversion.

Same family as gh-151295 (bytes.join, GH-151296) and gh-151370
(marshal.dumps, GH-151371). Triggering requires a custom __fspath__, so this
is a robustness / crash-hardening fix with no security impact; the NEWS entry is
under Library/.

• Issue: _posixsubprocess.fork_exec(): use-after-free if an argv item's __fspath__ mutates args #151403

[gpshead]

lets not add this test. it is perhaps useful for illustration purposes, but this is not specific to subprocess. it's C API misuse. FWIW, thanks! overall the rest of the PR looks good.

I've pointed claude fable at the antipattern to find and fixup others and improve the docs as a future prevention matter: #151416

[tonghuaroot]

Done — dropped the test. Agreed it's general C-API misuse rather than subprocess-specific. Thanks for the quick review!

[tonghuaroot]

Done — dropped the test. Agreed it's general C-API misuse rather than subprocess-specific. Thanks for the quick review!