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/tests/runtime.spec.ts

@@ -827,12 +827,24 @@ describe('PythonCodeRuntime — programs and bindings', () => {
       .rejects.toThrow(/maxValueBytes times the 12x worst-case Unicode expansion must fit/)
     // Discriminates 12 from 8: a 48 MiB maxLogBytes against a 512 MiB address
     // space leaves 448 MiB budgetable. 48*8 = 384 MiB fits (the old 8x multiple
-    // wrongly ADMITTED this), but 48*12 = 576 MiB does not — and this is exactly
-    // the config that OOMs, since a settlement flush holds the pending chunks,
-    // their join, and the encode copy at once (~12x). The 12x gate rejects it.
+    // wrongly ADMITTED this), but 48*12 = 576 MiB does not. The ~12x peak this
+    // guards is the NEWLINE path's single near-budget write — the caller's own
+    // string, the line slice, and the encode copy live at once. The settlement
+    // flush is no longer the binding case: `flush_line` drops the pending chunks
+    // before its push, so it holds two copies, not three.
     const ctxTwelve = new Context()
     await expect(ctxTwelve.plugin(PythonCodeRuntime, { maxLogBytes: 48 * 1024 * 1024, addressSpaceMb: 512 }))
       .rejects.toThrow(/maxLogBytes times the 12x worst-case Unicode expansion must fit/)
+    // An addressSpaceMb at or below the interpreter baseline leaves nothing
+    // budgetable, so no budget value can pass. It is rejected on its own terms:
+    // the budget loop would otherwise report "a limit of -1" (or -2796203 at
+    // 32 MiB) while naming maxLogBytes, sending the operator to the wrong knob.
+    const ctxBaseline = new Context()
+    await expect(ctxBaseline.plugin(PythonCodeRuntime, { addressSpaceMb: 64 }))
+      .rejects.toThrow(/addressSpaceMb must exceed the 67108864-byte interpreter baseline/)
+    const ctxBelow = new Context()
+    await expect(ctxBelow.plugin(PythonCodeRuntime, { addressSpaceMb: 32 }))
+      .rejects.toThrow(/addressSpaceMb must exceed the 67108864-byte interpreter baseline/)
     // The default caps against the default 512 MiB address space load.
     const ok = new Context()
     const fiber = await ok.plugin(PythonCodeRuntime, { maxLogBytes: 65536, maxValueBytes: 32768, addressSpaceMb: 512 })