BUG: Fix name qualification for inlined comprehensions in the exporter

[fumitoh]

Fixes two ways Model.export could generate wrong code for a name inside a list,
dict or set comprehension. Both live in FormulaTransformer.should_replace.

Found by exporting all 28 uslib/uklib/jplib models of lifelib:
DIA_US_S.Projection.result_annual came out with five bare names and raised
NameError on the first call. The other 27 exported clean.

1. Resolve the enclosing scope lexically (b450515)

PEP 709 (Python 3.12) inlines list, dict and set comprehensions into the enclosing
scope, so they no longer produce a symtable. adjust_scope_table_mapping compensates
by inserting None into self.symtables for each such scope, keeping it aligned with
self.scopes. should_replace then found the enclosing scope's table by scanning the
flat list backwards for the nearest non-None entry.

Nearest-earlier-table is not enclosing-scope. Generator expressions, lambdas and
nested defs all still own tables, and a comprehension only has to follow one of them
in the same formula to be resolved against it:

def with_genexp():
    ys = [1, 2]
    return {
        "a": [a(y) for y in ys],
        "b": [sum(b(t) for t in range(y)) for y in ys],
        "c": [c(y) for y in ys],       # resolved against the genexp's table -> bare
    }

enclosing_symbols replaces the scan and walks the libCST scope's own parent chain
until it reaches a scope that owns a table.

2. Never qualify a name the comprehension itself binds (c67e51f)

These two commits have to ship together. Resolving the scope correctly exposes the
fact that under PEP 709 the enclosing symtable is lossy: it cannot distinguish an
inlined comprehension's isolated target from a global of the same name. Commit 1 alone
regresses two shapes that main gets right:

shape	main	commit 1 alone
def f(t, u=[i for i in range(3)])	correct	u=[self.i for self.i in ...], and self does not exist while the generated class body executes, so the exported package fails to import
def f(): return d(1), [d for d in ys], with a lambda / genexp / nested def in between	correct	[self.d for self.d in ys]

The second is the dangerous mode: for self.d in ys is valid Python — an attribute is
a legal assignment target — so the exported model imports and runs, silently rebinds
the d Cells on the Space instance, and every later call to that Cells fails somewhere
that points nowhere near the formula that broke it.

comprehension_binds asks libCST instead, which records the binding in the
comprehension's own scope, where nothing is inlined and nothing is ambiguous. It also
closes the same defect in the no-intervening-scope case, def f(): return d(1), [d for d in ys], which was already wrong on main.

The first iterable is deliberately not covered: libCST records it in the enclosing
scope, exactly as Python evaluates it there, so [c for c in c] still qualifies the
iterable and leaves the two bound occurrences alone.

Python 3.11 and earlier are unaffected by either change. The None slots are inserted
only under sys.version_info >= (3, 12), so the backward scan never ran there, and a
comprehension that owns a symtable already reports its target as a local.

Tests

Eleven items in modelx/tests/export/test_export.py, off one module-scoped fixture,
following the test_cacheless.py idiom of asserting on getsource of the generated
method. Seven fail on main:

• comprehension after a generator expression, after a lambda, after a nested def
• a nested comprehension after a generator expression — the only shape that walks more
  than one level; the 28-model corpus never does
• a loop variable shadowing a Cells name, and one that is also read by name in the
  same formula, both with a runtime assertion that the Cells still answers after the
  formula has run
• a name bound by an outer comprehension and read inside an inner one

Four pass on main and are there to keep this change from regressing them: a
comprehension before any generator expression, a plain reference after one, a
comprehension in a parameter default, and the loop-variable-also-read case with an
intervening lambda.

Verification

• modelx/tests/export/ 50 passed; full suite 1405 passed, 6 skipped.
• Reproduced on main and fixed here under Python 3.12.9, 3.13.9 and 3.14.7. There is
  no 3.11-or-earlier interpreter on this machine, so that path is read from the code,
  not tested. (test_lifelib.py crashes on the free-threaded 3.14 build with a C-stack
  overflow inside modelx's own evaluation — pre-existing on main, unrelated.)
• Corpus: re-exporting all 28 uslib/uklib/jplib models at lifelib 6d5b078 changes
  exactly one hunk of 69,142 generated lines — the six lines of
  DIA_US_S.Projection.result_annual — and a symtable scan for names that resolve to
  nothing goes from 5 hits to 0.
• Exported from main, DIA_US_S.Projection.result_annual raises NameError; with
  this change it reproduces the modelx original frame for frame.
• The twelve models covered by test_lifelib.py export byte-identically. The only raw
  differences are the id() literals the exporter embeds for IO and pickle data, and a
  fixed-vs-fixed run produces the same noise, so it is not from this change.

For the reviewer

• The release note went into a new relnotes_v0_33_0.rst marked not yet released,
  following the draft pattern of 09671df, since 0.32.0 has shipped. Rename it if the
  next release is 0.32.1.
• I skipped the id(scope)-keyed dict tidy-up that would replace the linear scan in
  enclosing_symbols. Measured over 12 uslib models it is 0.98x — libCST parsing
  dominates and the scan is free. Happy to add it if you want it anyway.
• return self.name_to_symbol[0] in enclosing_symbols is a fallback that appears to
  be unreachable: instrumented over the 28-model corpus, 27,159 lookups never reached
  it. Left as a fallback rather than an assertion, but it could be either.
• Seven pre-existing exporter defects surfaced while working on this, none of them
  touched here. Filed separately as Exporter generates wrong or invalid code for several formula shapes #271.

🤖 Generated with Claude Code