feat: add get_note_outline and read_note_lines tools

[kartik7704]

adds two tools for efficient navigation of large notes without loading full file content into context:

get_note_outline — returns all headings with level, text, and line number
read_note_lines — reads a specific line range (1-indexed, inclusive)
Intended usage: call get_note_outline first to get the structure, then read_note_lines to read only the relevant section. Useful for large notes like logs or directories where loading the full content is wasteful.

[bitbonsai]

Sorry for the slow reply here, day-job has kept me busy.

Hey @kartik7704, thanks for putting this together. get_note_outline and read_note_lines both sound genuinely useful for working with long notes.

The branch is hard to review as-is though: it diverged before a big upstream refactor, so the diff currently shows ~139 changed files (website, dist, skills, the old tree) instead of just your feature. Could you rebase onto current main and resubmit with only the new tools plus their tests? Once the diff is just the feature, I'm happy to take a proper look.

[kartik7704]

Rebased onto current main. Turns out my fork's main was actually sitting on a September 2025 snapshot instead of last month (when i forked it), so it wasn't just normal drift.

The diff is now scoped to just the two new tools and their tests (12 files, down from 139). Also bumped the existing "server registers N tools" test since the new registrations change that count. All tests passing locally. Ready for your approval.

[bitbonsai]

Thanks for the clean rebase — this is exactly the diff I hoped for: feature-only, 31 new tests, green suite, dist in sync. get_note_outline and read_note_lines are both going to get real use.

Two things before I can merge:

1. readNoteLines skips the path guards. It needs the same normalizePath + pathFilter.isAllowed block readNote has (src/filesystem.ts:137) — right now read_note_lines can read .obsidian/ files that every other tool blocks.
2. parseOutline counts # lines inside fenced code blocks as headings. Track fence state (``` and ~~~) and skip those lines — patch_note has prior art for the fence handling.

Two smaller ones, take or leave: CRLF frontmatter (---\r\n) isn't skipped, and start/end clamping is asymmetric (end clamps, start errors — I'd clamp both and document it).

Happy to merge as soon as the two blockers are in. The structure (separate outline.ts with its own test file) is nice.

[kartik7704]

Both blockers are in:

1. getNoteOutline and readNoteLines now call normalizePath() before the pathFilter.isAllowed() check, matching every other method. Turned out getNoteOutline had the same gap even though only readNoteLines got called out, fixed both.
2. getNoteOutline now tracks fence state (``` and ~~~) and skips headings inside code blocks. One correction: I went looking for the patch_note fence-handling you mentioned as prior art and couldn't find it, `patchNote` is a plain string-replace, no fence logic anywhere in it. Wrote it fresh instead.

Also took the two smaller ones:

• getNoteOutline now skips the frontmatter block (LF and CRLF) before scanning, so a YAML comment doesn't get misread as a heading.
• readNoteLines clamps both startLine and endLine into valid bounds now instead of just endLine.

Added 6 tests covering fences, LF/CRLF frontmatter, and the three clamping edge cases. Full suite: 257 passing, dist rebuilt.