docs(code-runtime-python): correct the claims the new backend invalidated

Adding a published Python backend and reordering `flush_line` left several
owning documents stating things that are no longer true.

`src/invariant.ts` justified its empty installer with "ships only the fd-3
wire-protocol codec", which the subprocess execution path contradicts. The
reason now states the actual one: every relation this backend maintains lives
in the CPython child or on the fd-3 wire, so no same-process event sequence is
observable from a listener -- the same shape the sibling worker-thread backend
uses.

The seam's `PORTABLE_RESERVED_WORDS` and `language` JSDoc, the code-runtime
README pair, and docs/subsystems/code-runtime both said only TypeScript has a
published backend. Corrected in all four, with the generated cordis catalog
regenerated for the `language` change.

The note attributed the 12x multiple to the settlement flush holding three
copies. That stopped being true when `flush_line` was reordered to drop the
pending chunks before its push: the binding worst case is the newline path's
single near-budget write. Corrected in the note (both sides) and in the test
comment that repeated it.

The note's Testing section now registers the cases this stack added, and the
Chinese side receives the O(depth) entry it never got plus the new ones -- it
had drifted from the English.

`INTERPRETER_BASELINE_BYTES` argued 64 MiB from a RESIDENT set while RLIMIT_AS
bounds address space. It now cites the bootstrap's own measurement (30.23 MiB
of mappings for `python3 -I`), making 64 MiB roughly twice the measured
baseline.

Also: a hardcoded `(:232-235)` comment reference becomes a reference by name,
a "which now walks in O(depth) too" change narrative becomes a current-state
statement, and a stray double blank line is removed.

packages/code-runtime/code-runtime-python/py/bootstrap.py

@@ -363,8 +363,8 @@ class _LogStream(io.TextIOBase):
         # against them.
         with self._logs.lock:
             if self._pending:
-                # Join, drop the chunks, THEN push — the same order the newline
-                # path uses (:232-235). Pushing before the clear would keep the
+                # Join, drop the chunks, THEN push — the same join-clear-push order
+                # as `_write_locked`'s newline branch. Pushing before the clear would keep the
                 # pending chunks alive through `_push_locked`'s `text.encode`, so
                 # the chunks, their join, and the encode copy would all be live at
                 # once; dropping the chunks first leaves only the join and its
@@ -1184,8 +1184,8 @@ def _encode_json_plain(value: Any) -> str:
     # that pulls its children one at a time and writes each into the shared buffer,
     # rather than one stack entry (plus a separator marker) per child: a flat
     # `[0] * 6_000_000` encodes to ~12 MB but per-element frames are ~400 MB — an
-    # RLIMIT_AS death on a value `_check_done_value` already admitted (which now
-    # walks in O(depth) too). The output string is the only width-proportional
+    # RLIMIT_AS death on a value `_check_done_value` already admitted (it walks by
+    # depth as well). The output string is the only width-proportional
     # allocation, and its size the caller metered within budget. `io.StringIO`
     # accumulates without the intermediate `"".join(chunks)` second copy. A cursor
     # frame is [kind, iterator, wrote_any]; a visit frame is (VISIT, value).