perf: check disallowed items at name-resolution boundary, not every AST node

[edgarrmondragon]

Description

What is this PR doing?

Reduces the number of _check_disallowed_items calls by calling it once per name lookup instead of for every AST node.

Only ast.Name nodes are relevant because they are supplied by the caller, and no other ast.Name nodes are available in the simpleeval sandbox during evaluation (AFAICT!).

Pre-approval checklist (for submitter)

Please complete these steps

• Passes tests
• New tests for additional features or changed functionality
• My name and contribution added to contributors list (or if I'd rather opt out, I've said so in the PR)

Additional Context by Claude

simpleeval 1.0.5 introduced _check_disallowed_items(result) after every _eval(node) call to close CVE-2026-32640. The fix is correct but over-broad: it fires on every intermediate AST node (name lookups, attribute accesses, arithmetic sub-expressions, list comprehension elements, …) even though dangerous values can only enter the evaluator through the names dict.

PR #176 reduced the per-call cost of _check_disallowed_items (primitive fast-path, callable instead of is_hashable). This PR addresses the orthogonal problem: the call frequency. Instead of calling the check once per AST node, it is called once per name lookup — the single site where values cross the trust boundary from the caller's names/functions dicts into the evaluator.

Why this is safe

Attack vector	Blocked by
Bare module in names	_check_disallowed_items in _eval_name (this PR)
Module reached via attribute chain	existing isinstance(item, types.ModuleType) in _eval_attribute
DISALLOW_FUNCTIONS callable called directly	existing check in _eval_call
DISALLOW_PREFIXES (__/func_) attribute access	existing prefix loop in _eval_attribute
Container in names holding a module/disallowed callable	_check_disallowed_items recursion in _eval_name (this PR)

All existing tests continue to pass unmodified.

New tests

tests/test_check_boundary.py

Pins the performance property: the number of _check_disallowed_items calls equals the number of name lookups, not the total number of AST nodes evaluated.

tests/test_module_wrapper.py

• TestModuleNeedsWrapping — regression tests asserting that bare modules (including those nested inside lists or dicts) still raise FeatureNotAvailable.
• TestModuleWrapperAccess — extended with container-blocking cases and a EvalWithCompoundTypes chained-access case to confirm ModuleWrapper remains the correct opt-in path.

Performance impact

A downstream user (Meltano Singer SDK) first reported the regression in meltano/sdk#3565, which led to PR #176. Even after #176 landed, the SDK benchmark still showed a regression because the fundamental issue — O(AST nodes) calls rather than O(name lookups) — remained. The SDK counted 24 _check_disallowed_items calls per record transform (3 expressions × ~8 AST nodes each); this PR reduces that to the number of distinct name occurrences in those expressions.

Confirmed by meltano/sdk#3596: with this change applied, the SDK shows no performance regression whatsoever.

🤖 Generated with Claude Code

[edgarrmondragon]

FWIW tests are passing:

$ make test
python -Werror -m unittest
.....................................................................................................................................................................
----------------------------------------------------------------------
Ran 165 tests in 0.052s

OK