Remove IN_ARRAY_KEY_ASSIGN re-entry guard from forward walker

Author: AJenbo

docs/todo.md

@@ -25,7 +25,7 @@ within the same impact tier.
 
 | #   | Item                                                                                                                                                                | Impact      | Effort      |
 | --- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | ----------- |
-| P24 | [`IN_ARRAY_KEY_ASSIGN` re-entry guard in forward walker](todo/performance.md#p24-in_array_key_assign-re-entry-guard-in-forward-walker)                              | Low         | Low         |
+
 | P20 | [Forward walker: bounded iteration and depth-cap cleanup](todo/performance.md#p20-forward-walker-bounded-iteration-and-depth-cap-cleanup)                            | High        | Medium      |
 | ER5 | [Mago-style separated metadata](todo/eager-resolution.md#er5--mago-style-separated-metadata)                                                                        | High        | High        |
 | P9  | [`resolved_class_cache` generic-arg specialisation](todo/performance.md#p9-resolved_class_cache-generic-arg-specialisation)                                         | Medium      | Medium      |

docs/todo/performance.md

@@ -852,36 +852,3 @@ like:
 Most depth-cap and recursion-guard issues are addressed by P20
 (forward walker) and ER5 (class resolution). The items below are
 independent fixes that do not depend on either.
-
----
-
-## P24. `IN_ARRAY_KEY_ASSIGN` re-entry guard in forward walker
-
-**Impact: Low · Effort: Low**
-
-`forward_walk.rs` line ~3861 uses a thread-local `Cell<bool>` to
-break re-entry in `process_array_key_assignment` when
-`resolve_rhs_with_scope` triggers re-evaluation of the same array
-key (e.g. `$a['k'] = f($a['k'])`). This is a symptom of the
-forward walker calling back into expression resolution which calls
-back into the forward walker.
-
-### How Mago solves this
-
-Mago's forward pass never re-enters itself. Array key assignments
-are processed by recording the LHS target, resolving the RHS type
-in isolation (using the scope snapshot from before the assignment),
-and then updating the scope. The RHS resolution reads from an
-immutable scope snapshot, so it cannot trigger a write that would
-re-enter the assignment handler.
-
-### Fix
-
-When processing `$a['k'] = expr`, snapshot the scope before the
-assignment, resolve `expr` against the snapshot (read-only), then
-apply the result to the live scope. This eliminates the re-entry
-path entirely and the `IN_ARRAY_KEY_ASSIGN` guard can be removed.
-
----
-
-

src/completion/variable/forward_walk.rs

@@ -3859,24 +3859,6 @@ fn process_array_key_assignment<'b>(
     scope: &mut ScopeState,
     ctx: &ForwardWalkCtx<'_>,
 ) {
-    // Guard against infinite re-entry.  When `resolve_rhs_with_scope`
-    // triggers re-evaluation of the same array key assignment (e.g.
-    // `$a['k'] = f($a['k'])` where reading `$a['k']` re-enters
-    // through the scope resolver), bail out to break the cycle.
-    thread_local! {
-        static IN_ARRAY_KEY_ASSIGN: Cell<bool> = const { Cell::new(false) };
-    }
-    if IN_ARRAY_KEY_ASSIGN.with(|c| c.get()) {
-        return;
-    }
-    IN_ARRAY_KEY_ASSIGN.with(|c| c.set(true));
-    struct ArrayKeyAssignGuard;
-    impl Drop for ArrayKeyAssignGuard {
-        fn drop(&mut self) {
-            IN_ARRAY_KEY_ASSIGN.with(|c| c.set(false));
-        }
-    }
-    let _guard = ArrayKeyAssignGuard;
     // Delegate to the existing check_expression_for_assignment
     // infrastructure for array key assignments.  This handles
     // both string-keyed shape building and generic element tracking.