docs(tools): name both raw routes, complete the evaluation-floor list

The previous commit's `UNPRINTABLE` sentence said the raw-reach point for all
three characters is `pyScalar`'s `JSON.stringify`, and the test comment said
that route is the only one. Both are exclusive claims and both are false: the
subscript tool-name comment calls `JSON.stringify` itself, and a tool name
carrying NEL, LS, or PS always lands there, none of the three being
`XID_Continue`. `pyScalar`'s own docstring already recorded that inheritance,
so the file contradicted itself. Both sentences now name the two call sites.

The note's evaluation axis was introduced as "the `typing` names the block
spells", which excludes one of its own members (`A | B` is operator syntax)
and omitted PEP 585 builtin generics — `dict[str, Any]` and `list[…]` appear
in nearly every render and need 3.9. The axis is now "the names and syntax the
block would evaluate at definition time", enumerated 3.8 through 3.11.

The test title covered two of the three characters it asserts; NEL is NEXT
LINE, neither a line nor a paragraph separator.

packages/core/tools/src/py-types.ts

@@ -172,9 +172,11 @@ interface RenderState {
  * string at run time but do not end a physical line in source — measured on
  * CPython 3.9.6 and 3.12.13, each accepted in both positions with the value
  * round-tripping — so they are safe raw wherever they reach emitted text
- * unescaped, which for all three is {@link pyScalar}'s `JSON.stringify`: the
- * `description` path escapes NEL under the class above and folds LS and PS in
- * {@link describe}'s `\s+` collapse, both of them being ECMAScript `\s`.
+ * unescaped, which for all three is `JSON.stringify`, at two call sites:
+ * {@link pyScalar}'s literal path, and the subscript tool-name comment's own
+ * call, which a name carrying any of them always reaches, none being
+ * `XID_Continue`. The `description` path escapes NEL under the class above and
+ * folds LS and PS in {@link describe}'s `\s+` collapse, both being `\s`.
  */
 const UNPRINTABLE = /[\u0000-\u0008\u000e-\u001f\u007f-\u009f]/g
 

packages/core/tools/tests/py-types.spec.ts

@@ -67,7 +67,7 @@ describe('jsonSchemaToPy', () => {
     expect(jsonSchemaToPy({ type: 'string', const: 'ends\\' })).toBe(String.raw`Literal["ends\\"]`)
   })
 
-  it('passes the line and paragraph separators through raw, which CPython does not treat as line terminators', () => {
+  it('passes NEL and the line/paragraph separators through raw, which CPython does not treat as line terminators', () => {
     // `JSON.stringify` escapes LF and CR but not NEL (U+0085), LS (U+2028), or
     // PS (U+2029), which is safe here and not by accident: those three are
     // `str.splitlines()` boundaries, not tokenizer line terminators, so they
@@ -78,8 +78,9 @@ describe('jsonSchemaToPy', () => {
     // same bytes, and none of the three has a visible width.
     expect(jsonSchemaToPy({ type: 'string', const: 'a\u2028b' })).toBe('Literal["a\u2028b"]')
     expect(jsonSchemaToPy({ type: 'string', enum: ['a\u2029b'] })).toBe('Literal["a\u2029b"]')
-    // NEL is inside `UNPRINTABLE`'s class, so the description path escapes it;
-    // this is the one route that carries it raw.
+    // NEL is inside `UNPRINTABLE`'s class, so the description path escapes it.
+    // This is one of the two routes that carry it raw; the other is the
+    // subscript tool-name comment's own `JSON.stringify` call.
     expect(jsonSchemaToPy({ type: 'string', const: 'a\u0085b' })).toBe('Literal["a\u0085b"]')
   })