Pre-existing: create+update on same nodeId within debounce drops the update

[paperhurts]

Where

packages/extension-chrome/src/lib/listeners.ts — applyBatch update branch (around the idMap.ulidForNode(asNodeId(p.nodeId)) lookup).

What

If a user creates a bookmark and then renames it within the same 500ms debounce window, both events land in the same flush batch. The create event pre-mints a ULID in createUlids and sets the id-map after the write succeeds. But the update event runs through applyBatch BEFORE the create's id-map mutation is applied — idMap.ulidForNode(p.nodeId) returns undefined, the update branch continues, and the renamed title never reaches the first GitHub commit.

It does land on the NEXT user-driven event (e.g., a second rename) because by then the id-map is populated. But the first batch silently swallows the renamed title.

Why this is pre-existing

Not regressed by any of PRs #12-#17. The code path existed before — the recent surviving filter changes (issue #8) just made the analogous unmapped-update case explicit at the filter level.

Detected by

Second comprehensive PR review (code-reviewer agent, confidence ~80, flagged as a non-regressing finding worth tracking).

Suggested fix

Have the update branch consult createUlids first when idMap.ulidForNode returns undefined:

const ulid = idMap.ulidForNode(asNodeId(event.nodeId))
  ?? createUlids.get(event.nodeId);
if (ulid == null) continue;

This works because creates within the same batch have their ULIDs pre-assigned. Then addBookmark + updateBookmark in the same mutate produces a bookmark with the updated title in one shot.

Acceptance

• Test: dispatch onCreated for node-1 + onChanged for node-1 within one debounce → resulting bookmark has the updated title, not the original.
• Existing tests still green.