Stop getAllTasks reading every file from disk

[tgrosinger]

getAllTasks() scans every markdown file in the vault and called the async getTaskInfo() for each one. That method falls back to readFrontmatterFromFile() -> vault.read() whenever the metadata cache reports no frontmatter for a file, so a single getAllTasks() call could issue one uncached disk read per file.

Two things made this expensive:

• isValidFile() only filters excluded folders, so the scan covers every non-excluded note, not just task notes.
• getFileCache() returns null for files Obsidian has not indexed yet, so a scan running before the metadata cache is warm reads the entire vault.

NotificationService calls getAllTasks() on a 5 minute timer and once at startup, and StatusBarService calls it on every data-changed event when the tracked-tasks status bar item is enabled, so the reads repeat for as long as the plugin is loaded.

Two changes:

• getAllTasks() now uses getCachedTaskInfoSync(), the existing metadataCache-only lookup already used by the Bases views. A vault-wide scan should not touch the filesystem.
• getTaskInfo() only falls back to a disk read when getFileCache() returns null (file not yet indexed). An indexed file that reports no frontmatter genuinely has no YAML block, so reading it cannot surface anything the cache is missing.

The write-through path for files TaskNotes just wrote is unaffected; that is handled by pendingTaskInfoByPath, not by the disk read. The disk fallback for genuinely unindexed files (issue #1302) is preserved for direct single-path getTaskInfo() calls.

[callumalpass]

Thanks, @tgrosinger, much appreciated. I reproduced the repeated vault reads and confirmed that the metadata-cache path removes them. I made a small variation as part of the merge: getAllTasks() keeps its existing fallback semantics, while the notification and status-bar hot paths use a new cache-only enumeration method. This preserves recovery for temporarily unindexed tasks while ensuring recurring scans never touch disk.