Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@apps/desktop/src/renderer/App.tsx`:
- Around line 238-249: getNotebookTree currently hardcodes noteCount to 0 in
mapNode; instead read the real count exposed by the bridge or omit the field.
Update the TreeNode type and the mapNode mapping inside getNotebookTree to use
the bridge-provided value (e.g., node.notebook.noteCount) for noteCount and keep
childCount computed from node.children.length (or if the bridge does not provide
noteCount, remove noteCount from the returned shape). Ensure you reference
getNotebookTree, the local TreeNode type, mapNode and
window.readied.notebooks.tree() when making the change.
- Around line 223-233: searchNotes currently ignores options.notebookId and
countNotes ignores options entirely; update searchNotes (the async
searchNotes(query, options) method) to pass through options.notebookId (and
preserve options?.limit ?? 20) to window.readied.notes.search so the backend is
scoped correctly, and change countNotes to accept an options parameter and
forward it to window.readied.notes.count (e.g.,
window.readied.notes.count(options)) so counts match the same query scope; keep
existing return shapes unchanged.
- Around line 196-216: getNotes is currently applying limit/offset when calling
window.readied.notes.list and then filtering the page, which yields incorrect
paging and total; change getNotes to fetch the unpaged list (call
window.readied.notes.list without limit/offset or with a flag to fetch all),
apply notebookId/status/isPinned filters to produce the full filtered array,
compute total = filtered.length, then apply limit/offset slicing to the filtered
array before mapping to the returned notes shape—refer to getNotes and
window.readied.notes.list to locate the call to adjust.
- Around line 197-203: The code replaces sortBy: 'wordCount' with 'updatedAt'
before calling window.readied.notes.list, changing requested semantics; instead
keep the original options when calling window.readied.notes.list and, if
options.sortBy === 'wordCount', post-process the returned notes array (the notes
variable) to sort by each note's wordCount field according to options.sortOrder
before using it, or alternatively return an error/throw when the bridge doesn't
support wordCount sorting; update the block around window.readied.notes.list and
the variable notes to implement client-side sorting (or rejection) rather than
remapping to 'updatedAt'.
- Around line 325-327: The code only calls dataAPI._notifyNotesChanged on
create/delete; update paths (title edits, content saves, moves, pin/archive
toggles, status changes) must also emit notifications so plugin caches stay in
sync: locate all handlers that mutate note data (the createNote callback and the
other mutation handlers referenced near the create block and around the region
flagged at 434-437), and add calls to dataAPI._notifyNotesChanged({ kind:
'note', action: '<appropriate-action>', id: note.id }) after each successful
mutation — using action values like 'updated' for edits/saves, 'moved' for
moves, 'pinned'/'unpinned', 'archived'/'unarchived' or more specific actions as
appropriate — and ensure appAPI._notifyNoteCreated / deleted patterns are
mirrored for these update handlers so subscribers receive updates consistently.

In `@docs/plans/2026-03-11-data-access-api-design.md`:
- Around line 15-23: The fenced code block showing the data-access flow is
unlabeled and triggers MD040; add a language tag (e.g., "text") to the opening
fence so the block is a labeled plain-text snippet. Update the block that
documents createDataAPI(), DataAPIBridge, window.readied.notes.list,
ipcRenderer.invoke('notes:list'), and SQLiteNoteRepository.list to start with
```text (or another appropriate language) instead of just ``` so the markdown
linter stops flagging it.

In `@docs/plans/2026-03-11-data-access-api-implementation.md`:
- Line 636: Update the wording in the docs to use "same" instead of "exact same"
in the sentence describing the pattern for appAPI; specifically edit the
sentence that reads "Follow the exact same pattern as `appAPI` — it's passed
into `activate()`, tracked for event cleanup, and injected into the `context`
object." to "Follow the same pattern as `appAPI` — it's passed into
`activate()`, tracked for event cleanup, and injected into the `context`
object." Keep references to `PluginRegistry.activate()` and the new `dataAPI`
parameter untouched.
- Around line 1-13: The markdown skips an H2 between the document title and
tasks; update the heading hierarchy by either inserting an H2 before the task
list (e.g., a section like "## Tasks" after "Data Access API Implementation
Plan") or demoting "### Task 1" (and subsequent task headings) to H2 (change
"### Task 1" to "## Task 1") so the heading progression follows H1 → H2 → H3 and
satisfies markdown lint rules.

In `@packages/plugin-api/src/data/createDataAPI.ts`:
- Around line 3-24: Combine the two import statements at the top of
createDataAPI.ts into a single import so types and the runtime value are grouped
together: merge the long type-only import list (NoteInfo, NoteSummaryInfo,
NotebookInfo, NoteQueryOptions, NoteQueryResult, SearchOptions, SearchResult,
NotebookQueryOptions, NotebookDetailInfo, NotebookTreeNode, NotebookResult,
TagQueryOptions, TagInfo, GraphQueryOptions, LinkInfo, OutgoingLinkInfo,
GraphData, DataChangeEvent) with the DataAccessError import so there is no blank
line between import groups and the linter warning is resolved.
- Around line 212-222: The _notify* methods (_notifyNotesChanged,
_notifyNotebooksChanged, _notifyTagsChanged) iterate directly over listener Sets
(notesChangedListeners, notebooksChangedListeners, tagsChangedListeners) which
can misbehave if listeners are added/removed during dispatch; fix by taking a
snapshot of each Set (e.g., Array.from(...) or [...set]) and iterate over that
snapshot so additions/removals during callbacks won’t affect the current
dispatch order or cause skipped callbacks.

In `@packages/plugin-api/src/data/dataTypes.ts`:
- Around line 68-87: GraphQueryOptions.depth is declared but ignored by
getGraphData in createDataAPI.ts; update getGraphData to respect
GraphQueryOptions.depth by performing a breadth‑first traversal from initial
nodes (filtered by notebookId if provided), track visited node IDs, stop
expanding neighbors once the specified depth is reached, and collect nodes and
edges into the GraphData result; alternatively, if you prefer not to implement
traversal now, update the GraphQueryOptions or getGraphData JSDoc comment to
state that depth is reserved for future use so callers know it is currently
ignored. Ensure you reference GraphQueryOptions.depth, getGraphData, and the
GraphData node/edge shapes when making the change.

---

Outside diff comments:
In `@packages/plugin-api/tests/registry.test.ts`:
- Around line 103-127: The test "it('passes context with all expected APIs')"
never asserts PluginContext.data; update the test after receiving
receivedContext (cast to ctx) to assert ctx has a data property and that it is
the DataAPI passed into registry.activate (use the existing mockDataAPI), e.g.
add assertions like expect(ctx).toHaveProperty('data') and
expect(ctx.data).toBe(mockDataAPI) so the activation contract verifies the
DataAPI is routed through registry.activate/activate.