[codex] Fix notebook SDK race after createLocal

[jlewi]

Summary

• wait for a newly opened notebook to become resolvable before runtime helpers return
• cover the async notebook materialization path in appkernel regression tests

Root cause

notebooks.createLocal() opened the new notebook and immediately called notebooks.get({ uri }). In the app runtime, opening a notebook only updates currentDoc first, while NotebookContext creates the NotebookData model later in an effect. That left a short window where resolveNotebook(uri) returned null, causing No notebook found for the requested target. even though creation and saving had already succeeded.

Impact

• await notebooks.createLocal("...") now returns reliably in App Console / appkernel flows
• helpers that switch notebooks and then keep operating on the opened notebook use a consistent readiness contract

Validation

• pnpm -C app exec vitest run src/lib/notebookData.test.ts
• runme run build --project /Users/jlewi/git_runmeweb --ignore-pattern .worktrees
• runme run test --project /Users/jlewi/git_runmeweb --ignore-pattern .worktrees

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8b67323014

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Remove fixed 1.5s notebook-open deadline

waitForOpenedNotebook now fails after a hard-coded 1500ms even when openNotebook succeeded, which can make notebooks.createLocal(...), drive.saveAsCurrentNotebook(...), and app.openNotebook(...) throw spuriously on slower devices, large notebooks, or background-tab timer throttling. In this flow, notebook materialization is asynchronous (CurrentDoc change → context effect → model creation), so a strict 1.5s cap introduces a new user-visible failure mode where the notebook opens eventually but the helper rejects.

Useful? React with 👍 / 👎.

[jlewi]

I think we need to rethink this but I forgot exactly how; I think there was a bigger refactor of the SDK we potentially needed to do.