Cursor AI tab completion (ghost text) only works in cell 1, not cells 2+

### Describe the bug Cursor's AI inline tab completion (ghost-text / \"Tab\" completions) only triggers in the **first cell** of a marimo notebook. Typing in cells 2 and beyond produces no inline suggestions at all. This reproduces with a notebook of any size (tested with 6 cells). The issue is present in the published extension (0.11.4). Notably, Jupyter notebooks work correctly in all cells — so this appears to be specific to marimo's notebook implementation. ### Steps to reproduce 1. Open any `.py` marimo notebook with 2+ cells in Cursor 2. Click into cell 1 and start typing — ghost-text completions appear ✓ 3. Click into cell 2 and start typing — no completions appear ✗ ### Expected behavior Cursor AI tab completion triggers in all cells, not just cell 1. ### Suspected root cause This hasn't been fully diagnosed, but here's what we've found so far. Cursor's tab completion (CPP) service registers a `onDidChangeContent` listener for each notebook cell editor. When content changes, it runs a deduplication check along the lines of: ``` modelListeners.get(relativePath).size > 1 && editor.getId() !== getActiveCodeEditor()?.getId() ``` Because all marimo cells share the same notebook file's relative path (e.g. `demo.py`), `size` equals the total number of cells and is always `> 1`. This means completions only fire for whichever cell Cursor considers the "active code editor." Cell 1 works because it is auto-focused when the notebook opens. The hypothesis is that when switching to cells 2+, something about how marimo notebook cells are initialized or focused doesn't update Cursor's internal active-editor state in time — so the check always evaluates against cell 1's editor ID. Jupyter notebooks may work because their cell editors update this state differently (possibly due to VS Code's built-in Jupyter handling, or the Jupyter extension doing something explicit on cell focus). We attempted a workaround — registering `onDidChangeNotebookEditorSelection` and calling `showTextDocument(cell.document, { preserveFocus: true })` on cell selection to eagerly update the active editor — but this caused visible UI flickering without fixing the problem, suggesting the mechanism is deeper than simple active-editor tracking. The root cause may lie in how marimo cell editors are registered with VS Code's `ICodeEditorService`, how focus events propagate for the `marimo-notebook` type, or a timing difference between when `onDidChangeContent` fires and when the active editor state is updated. A comparison of how Jupyter vs. marimo notebook controllers and serializers set up cell editors would likely be revealing. ### Environment - Cursor (latest) - marimo VS Code Extension 0.11.4 - macOS 15 (Apple Silicon)