Add failing tests for go-to-definition scope bugs

Three known bugs in the new scope-aware go-to-definition path.

Set comprehensions never create a scope because SCOPE_CREATING_NODES
uses "SetComprehension" but the Lezer Python grammar emits
"SetComprehensionExpression" — go-to-def on the expression `x` in
`{x for x in ...}` falls back to first-match and lands on an outer
`x` instead of the for-target. A dict-comprehension test uses the
grammar-correct name and passes as a positive control.

`getScopeChain` walks straight up the syntax tree and pushes any
ClassDefinition ancestor onto the chain, but in Python a method
body does not see its enclosing class scope. Once a function or
lambda boundary has been crossed walking outward, class scopes must
be skipped. With the current behavior, go-to-def on `x` inside a
method finds the class-body `x` instead of the module-level `x`.

POSITION_SENSITIVE_SCOPES includes "global", so a module-level
declaration whose position is after the usage is filtered out. From
inside a function that forward-references a later top-level name,
the lookup returns null and the fallback first-match lands on the
usage itself. Class-scope semantics need the position filter; module
scope does not.

The utils.test.ts mocks also drop the `as never` casts in favor of
fully-populated CellHandle literals, so a future field addition will
surface as a typecheck error.

Author: manzt

frontend/src/core/codemirror/go-to-definition/__tests__/commands.test.ts

@@ -147,6 +147,116 @@ def my_func(a):
     `);
   });
 
+  test("selects the comprehension target inside a set comprehension", async () => {
+    const code = `\
+x = 100
+s = {x for x in range(10)}`;
+    view = createEditor(code);
+    // Go-to-definition on the `x` before `for` (the expression part of the
+    // comprehension).
+    const usagePosition = code.indexOf("{x") + 1;
+    const result = goToVariableDefinition(view, "x", usagePosition);
+
+    expect(result).toBe(true);
+    await tick();
+    // Should jump to the comprehension target `x` (after `for`), not the
+    // outer `x = 100`. The Lezer Python grammar emits
+    // `SetComprehensionExpression`, but the code looks for `SetComprehension`,
+    // so the comprehension never creates a scope and the for-target is not
+    // collected — `findScopedDefinitionPosition` returns null and the
+    // fallback `findFirstMatchingVariable` lands on `x = 100`.
+    expect(renderEditorView(view)).toMatchInlineSnapshot(`
+      "
+      x = 100
+      s = {x for x in range(10)}
+                 ^
+      "
+    `);
+  });
+
+  test("selects the comprehension target inside a dict comprehension", async () => {
+    const code = `\
+x = 100
+d = {x: x for x in range(10)}`;
+    view = createEditor(code);
+    const usagePosition = code.indexOf("{x") + 1;
+    const result = goToVariableDefinition(view, "x", usagePosition);
+
+    expect(result).toBe(true);
+    await tick();
+    // Positive control: `DictionaryComprehensionExpression` matches the grammar
+    // and is in SCOPE_CREATING_NODES, so this should jump to the comprehension
+    // target `x` (after `for`).
+    expect(renderEditorView(view)).toMatchInlineSnapshot(`
+      "
+      x = 100
+      d = {x: x for x in range(10)}
+                    ^
+      "
+    `);
+  });
+
+  test("skips enclosing class scope when resolving from inside a method", async () => {
+    const code = `\
+x = 100
+class Foo:
+    x = 10
+    def method(self):
+        return x`;
+    view = createEditor(code);
+    // Go-to-definition on the `x` inside `return x`.
+    const usagePosition = code.lastIndexOf("x");
+    const result = goToVariableDefinition(view, "x", usagePosition);
+
+    expect(result).toBe(true);
+    await tick();
+    // Should jump to `x = 100` at module scope. In Python, methods do NOT see
+    // their enclosing class body's names — class scopes are skipped in LEGB
+    // lookup once a function boundary has been crossed. `getScopeChain` walks
+    // straight up and pushes the `ClassDefinition` onto the chain, so the
+    // method's lookup finds the class-body `x = 10` instead.
+    expect(renderEditorView(view)).toMatchInlineSnapshot(`
+      "
+      x = 100
+      ^
+      class Foo:
+          x = 10
+          def method(self):
+              return x
+      "
+    `);
+  });
+
+  test("resolves a global forward-reference from inside a function", async () => {
+    const code = `\
+def foo():
+    return a
+
+a = 10`;
+    view = createEditor(code);
+    // Go-to-definition on the `a` inside `return a`.
+    const usagePosition = code.indexOf("return a") + "return ".length;
+    const result = goToVariableDefinition(view, "a", usagePosition);
+
+    expect(result).toBe(true);
+    await tick();
+    // Should jump to `a = 10` at the bottom. Python allows forward references
+    // from within nested functions to module-level names. POSITION_SENSITIVE_SCOPES
+    // includes `"global"`, so the global declaration is filtered out (its `from`
+    // is after the usage), the lookup returns null, and the fallback
+    // `findFirstMatchingVariable` lands on the `a` inside `return a` — i.e.
+    // go-to-definition jumps to itself.
+    expect(renderEditorView(view)).toMatchInlineSnapshot(`
+      "
+      def foo():
+          return a
+
+      a = 10
+      ^
+      "
+    `);
+  });
+
   test("selects outer-scope function declaration", async () => {
     view = createEditor(`\
 def x():

frontend/src/core/codemirror/go-to-definition/__tests__/utils.test.ts

@@ -56,11 +56,11 @@ def test():
 
     const notebook = initialNotebookState();
     notebook.cellHandles[globalCell] = {
-      current: { editorView: globalView },
-    } as never;
+      current: { editorView: globalView, editorViewOrNull: globalView },
+    };
     notebook.cellHandles[localCell] = {
-      current: { editorView: localView },
-    } as never;
+      current: { editorView: localView, editorViewOrNull: localView },
+    };
 
     store.set(notebookAtom, notebook);
     store.set(variablesAtom, {