Improve performance of dashboard and grouped views in large vaults

[soler1212]

Description:
Currently, vaults with a large number of notes (e.g. 15,000+) experience noticeable lag or even become unresponsive when loading the Status Dashboard and Grouped Status View.

To mitigate this, a temporary workaround was added in PR #44 to disable both views when the vault exceeds a configurable limit (vaultSizeLimit), with a default of 15,000 notes.

However, this does not address the core performance issue. This issue aims to track potential long-term improvements to allow these views to work efficiently even in large vaults.

---

Possible directions for investigation:

• Incremental indexing:

  • Instead of scanning all files on each render via getMarkdownFiles(), build and maintain an internal cache (e.g. using metadataCache, pluginData) that tracks relevant notes and updates it reactively on vault.on("create"), vault.on("delete"), metadataCache.on("changed"), etc.

• Early filtering:

  • Only include notes that are relevant (e.g. with frontmatter statuses) before passing data to the UI. Avoid unnecessary computation or rendering of unrelated files.

• Smarter use of metadataCache:

  • Avoid opening or reading note contents unnecessarily. Use the metadata already indexed by Obsidian wherever possible.

• Virtualized or chunked rendering:

  • Since libraries like react-window might not be viable in the Obsidian environment, consider building a custom paginated or chunked rendering strategy to avoid mounting thousands of DOM elements at once.

• Deferred rendering:

  • Use techniques like requestIdleCallback or batched setTimeout rendering to split up work and keep the UI responsive.

• Skip expensive stats:

  • Disable or defer rendering of heavy aggregations (e.g. grouped counts) when not strictly needed.

---

Expected outcome:
The dashboard and grouped views should:

• Load reliably and quickly even with >15k notes.
• Not block the UI.
• Scale gracefully with vault size.