gh-144161: Clarify additional immortalization in free-threaded build

Doc/c-api/unicode.rst

@@ -1753,6 +1753,8 @@ They all return ``NULL`` or ``-1`` if an exception occurs.
    Note that interned strings are not “immortal”.
    You must keep a reference to the result to benefit from interning.
 
+   .. note::
+      In the free-threaded build, all interned strings are :term:`immortal`.
 
 .. c:function:: PyObject* PyUnicode_InternFromString(const char *str)
 

Doc/howto/free-threading-python.rst

@@ -99,12 +99,12 @@ This section describes known limitations of the free-threaded CPython build.
 Immortalization
 ---------------
 
-In the free-threaded build, some objects are :term:`immortal`.
+The free-threaded build introduces additional :term:`immortal` objects.
 Immortal objects are not deallocated and have reference counts that are
 never modified.  This is done to avoid reference count contention that would
 prevent efficient multi-threaded scaling.
 
-As of the 3.14 release, immortalization is limited to:
+As of the 3.14 release, this additional immortalization is limited to:
 
 * Code constants: numeric literals, string literals, and tuple literals
   composed of other constants.

Doc/library/sys.rst

@@ -1325,6 +1325,9 @@ always available. Unless explicitly noted otherwise, all variables are read-only
    Interned strings are not :term:`immortal`; you must keep a reference to the
    return value of :func:`intern` around to benefit from it.
 
+   .. note::
+
+      In the free-threaded build, all interned strings are :term:`immortal`.
 
 .. function:: _is_gil_enabled()