Path tree nav — contextual sidebar for path-organized vaults

[unforced]

Why

For vaults that use paths meaningfully (like Aaron's, with Canon/, Current/, Uni/Decisions/, etc.), a collapsible tree nav transforms browsing. For vaults that are path-flat (all notes at root, tag-organized), a tree nav is cruft.

Aaron: "how this would work as far as indexing goes... paths and tags might be doing similar work."

Paths and tags are genuinely different primitives: path = unique hierarchical location, tag = categorical label. They're not duplicates. But UI-wise, both filter the list — so a user with no paths doesn't benefit from a path tree.

Proposal: contextual — show tree when meaningful

On load, inspect the vault's note paths:

• Count distinct path prefixes at depth ≥ 2
• If significant (say ≥ 5 distinct top-level folders OR ≥ 20 notes with multi-segment paths), show path tree in /notes sidebar
• Otherwise, don't render the sidebar — keeps mobile and light vaults clean

Setting toggle in settings: "Show path tree" → auto / always / never.

Scope

• PathTree component: collapsible tree rendered from unique path prefixes
• Click a folder node → sets path_prefix filter
• Fetched once + cached via TanStack Query; invalidated on note create/rename/delete
• Sidebar layout on /notes: tree on left, list on right (desktop); collapsed drawer on mobile
• Auto-detect meaningful structure on first load, user can override in settings

Implementation notes

• The path tree doesn't fetch a distinct endpoint — derives from the existing notes query. For large vaults where "all notes" fetch is expensive, we'd need a vault-side /api/paths endpoint returning just distinct path prefixes. Mark as vault dependency IF Aaron wants this before a particular scale.
• Tree state (expanded/collapsed) persisted in localStorage per vault
• Don't make folders a write-surface in v1 — they're read-only nav. "Create a note in folder X" happens via /new where user types the path.

⚠️ Possible vault dependency

For very large vaults, fetching all notes to derive the path tree is wasteful. A lightweight /api/paths endpoint returning distinct prefixes would be better. Check with Aaron before adding this as a vault-side change.

Tests

• Tree renders correct structure from sample paths
• Click applies path_prefix filter
• Auto-detect threshold works on tag-flat vs. path-rich sample vaults

Out of scope

• Drag-to-rename (moves a note to a new path) — future
• Folder-level operations (bulk tag, bulk delete) — separate issues
• Multi-vault tree merging — no

Priority

Mid-low. Useful but contextual. Don't block the tighter v0.3 arc on this.