fix(calculator): block sympify string-eval escape without breaking safe constructors

[yonib05]

Summary

The calculator's expression evaluator validates each expression against an AST allowlist before evaluation. Some functions exposed in the safe locals (for example N, simplify, and solve) accept string arguments and re-parse them through SymPy's sympify, which evaluates that string in a namespace separate from the restricted one used for the top-level expression. As a result a string-literal argument to one of those functions is not subject to the same restrictions as the surrounding expression, which allows code execution (for example simplify("__import__('os').system('...')")).

This change rejects string literals during AST validation, except when they appear as positional arguments to the symbol/number constructors that parse their string as a plain name or numeric literal rather than through sympify: Symbol, symbols, Rational, Integer, and Float. These constructors do not re-evaluate their argument, so they cannot be used to escape the sandbox, and keeping them allowed avoids breaking the documented Symbol('x') / Rational('1/3') syntax.

Changes

• Reject string-literal ast.Constant nodes in _validate_expression_ast, allowing them only as positional arguments to the safe string constructors (Symbol, symbols, Rational, Integer, Float).
• Add regression tests: string-literal arguments to the sympify-backed functions are rejected and do not execute code; the safe string constructors remain accepted and a malicious string passed to Symbol() becomes a symbol name rather than executing.
• Update the module and tool docstrings to describe the positional exception.

Backward compatibility

Not a breaking change. String-argument constructors that were previously valid and safe (Symbol('x'), symbols('x y z'), Rational('1/3'), Integer('5'), Float('3.14')) continue to work. Only string literals in positions that reach sympify (for example N("..."), simplify("..."), solve("...")) or in other non-constructor positions are rejected.

Testing

• pytest tests/test_calculator.py tests/test_calculator_precision.py (81 passed)
• ruff format --check and ruff check on the changed files (clean)

[yonib05]

/strands-ts review

[github-actions]

Review — LGTM ✅

I reviewed the change, ran the suite, and did hands-on security probing. This is a well-scoped, correct hardening of the AST allowlist.

Verification

• pytest tests/test_calculator.py tests/test_calculator_precision.py → 85 passed
• ruff format --check + ruff check on changed files → clean

Security probing (manual)

• Rejected: N("..."), simplify("..."), solve("..."), factor("..."), expand("..."), integrate("...", x), nested Symbol(simplify("...")), string in keyword position (Symbol('x', foo="...")), and bytes literals everywhere.
• Allowed (backward compatible): Symbol('x'), symbols('x y z'), Rational('1/3'), Integer('5'), Float('3.14'), and normal math.
• Confirmed no code execution: a malicious string passed to Symbol() becomes a symbol name and never runs (verified with a filesystem marker that stays absent).

Why the constructor exception is safe

I checked the concern that a maliciously-named symbol could later be re-parsed: sympify does not re-parse a Symbol's name (N(Symbol('x + y')) stays a single symbol, not x + y). So smuggling a string in via Symbol('…') and passing it to a sympify-backed function does not create a bypass. The allowlisted constructors (Symbol, symbols, Rational, Integer, Float) only parse names/numeric literals, not arbitrary expressions.

Notes (non-blocking)

• The two ast.walk(tree) passes are fine — clarity over micro-optimization, and expression ASTs are tiny.
• The behavior change to the quoted string-list system syntax ("['x + y - 10', ...]") is well-justified: it was never functional and is now cleanly rejected with a clear error. Good call adding an explicit regression test for it.

Test coverage is thorough (attack vectors, no-exec side-effect checks, positive math, positional-vs-keyword, bytes). No changes requested from me.