[sanity]

Problem

In the editor, picking "+ Create ..." from the [[ autocomplete called state::create_page, which sets CURRENT_PAGE to the new page. The handler then set EDITING = false ("switch back to the page we were editing") but never restored CURRENT_PAGE, so the user landed on the new empty page and the draft, including the link just inserted, was thrown away (#68).

Approach

• state::create_page is split into add_page (adds the page and returns Some(id), does not navigate, and changes nothing when it returns None) and create_page (add_page and then open it in the editor). The sidebar's "+ New Page" still uses create_page. For non-owners, create_page is now a no-op. Before, it pointed CURRENT_PAGE at a page that didn't exist, but the button is owner-only anyway.
• Autocomplete picks go through insert_link_target(LinkTarget, pos), which replaces the u64::MAX sentinel. For New it uses add_page, so CURRENT_PAGE and EDITING never change. The seeding effect from fix(ui): stop the editor re-seeding over an in-progress edit #64 sees the same page identity and a buffer that no longer matches what it seeded, so it leaves the draft alone.
• The new id comes from add_page's return value. The old next_page_id - 1 was wrong when no page was added.
• An open [[query before the cursor is checked before creating anything, so a stale cursor can't leave an orphan page. The query span is rejected if it contains ]] or a newline, the same rule update_autocomplete uses.
• Also fixed while there: the keyboard Enter/Tab path rebuilt the candidate list without excluding the current page, while the dropdown excludes it, so the highlighted row and the inserted link could differ. It now indexes the rendered list, through selected_link_target.
• AGENTS.md's page-order invariant and the allocation comments now name add_page, which owns id and order allocation.

Testing

• VirtualDom tests in editor.rs (reseed_tests) mount the real Editor:
  • creating_a_page_from_autocomplete_keeps_the_draft_and_the_link checks that the editor stays on page 1 and stays open, and that the buffer is intro [[<new id>]] and the rest with the retitle kept. The draft also survives a handle_signed_page-shaped replacement of the new page in SITES. There is a positive control showing the seeding effect is live. Mutation-checked: making the create branch move CURRENT_PAGE again makes the test fail.
  • ..._on_a_site_we_do_not_own_changes_nothing checks that no page is added, no link is inserted, and CURRENT_PAGE is unchanged.
  • create_page_still_opens_the_new_page_in_the_editor guards the sidebar path.
• Unit tests:
  • selected_link_target: maps a row index to a page or to the Create row.
  • splice_link: covers a stale or mid-multibyte cursor, a closed link, and a newline.
• No event-level test covers the keydown handler, because the harness does not simulate key events. The handler is now a one-line call into the tested selected_link_target, using the same Vec the dropdown iterates.
• These pass locally: cargo fmt --check, cargo clippy --all-targets -- -D warnings, cargo test (delta-ui: 248 passed), and the wasm32 check.

Review

Light tier with two lenses (skeptical, code-first). The first pass found nothing blocking. Its should-fix findings were the untested dispatch and keyboard path, the untested delegate-response path, the orphan page on a stale cursor, and the stale AGENTS.md and comments. All are addressed in be9bfd9, and that head has been re-reviewed.

This is a UI-only change, so the contract and delegate WASM are untouched. It needs a Delta UI republish to reach users.

Closes #68

[AI-assisted - Claude]
https://claude.ai/code/session_01GKBuAzByqMPegsXcUYJb7h