fix(executor): evaluate augmented assignment targets once

[chuenchen309]

What

evaluate_augassign() currently evaluates subscript and attribute target expressions twice: once in get_current_value() to read the old value, and again in set_value() to store the result. Python evaluates the target object and subscript key only once for augmented assignment.

A side-effecting target can therefore read from one location and write the result to another:

values = [1, 2]
calls = [0]

def next_index():
    index = calls[0]
    calls[0] += 1
    return index

values[next_index()] += 10

Native Python produces values == [11, 2] with one call. The local executor produced values == [1, 11] with two calls: it read values[0], then re-ran next_index() and stored that result into values[1].

Attribute targets had the same problem. next_box().value += 10 read from the first returned object, then called next_box() again and wrote the result onto the second object.

Fix

Resolve subscript objects/keys and attribute objects once before evaluating the right-hand side, then reuse those exact references for the final store. Name targets and the operation dispatch are unchanged; the general-purpose set_value() helper is also unchanged.

This also preserves Python's evaluation order: target object, subscript key (if any), right-hand side, operation, then store.

Testing

Added two parametrized regression cases covering side-effecting subscript and attribute targets.

• Before the fix: both new cases failed with ([1, 11], 2) instead of ([11, 2], 1).
• After the fix: both new cases pass.
• Full tests/test_local_python_executor.py: 399 passed, 2 skipped.
  • The first full run had one unrelated timing failure in TestTimeout.test_timeout_decorator_raises_error_when_exceeded; it passed immediately in isolation, and the complete file then passed on rerun.
• ruff check and ruff format --check: clean.
• git diff --check: clean.

Duplicate-work check

Checked every currently open PR page (roughly 500 PRs), including changed file paths. Many open PRs touch this hot executor file, but none of their diffs touches evaluate_augassign or claims this evaluation-order bug. Also inspected the merged historical augassign PRs #285 and #313; they implemented/refactored operator dispatch and do not address repeated target evaluation.

AI disclosure

Developed with AI assistance (Codex), which surfaced the candidate during a targeted executor review. I independently reproduced both wrong-write cases against the real evaluator, audited all open PR file overlaps and the historical augassign changes, reviewed the implementation, and ran the focused and full tests before submitting.