[jdrews]

Fixes #40

Problem

Adding a library folder whose .mid files are symlinks (e.g. an artist-index tree linking into a flat store) yields an empty library — only folders containing regular files load.

Root cause

fs:scanMidiFolder (electron/main.ts) uses readdirSync(dir, { withFileTypes: true }) and branches on e.isDirectory() / e.isFile(). Dirent reports the entry's own type, never its target — for a symlink both are false, so every symlinked file fell through both branches and was silently dropped.

Fix

• Extract the walk into electron/libraryScan.ts (scanMidiFolder) and resolve symlinked entries with statSync, which follows links, to get their real type
• Skip broken symlinks silently (consistent with the handler's existing handling of unreadable directories)
• Track visited directories by real path so a symlinked subfolder pointing at an ancestor (or a symlink cycle) cannot recurse forever; a directory reached twice (real path and link) is listed once
• Add electron/libraryScanTest.ts covering regular files, file/dir links, broken links, dedup and a cycle — the symlink checks no-op gracefully where the OS won't permit creating them

Verification

• npm test: 61 files run, 0 failures; npm run typecheck clean
• Old vs. new scan logic over a real symlinked library (folder A of a ~100k-file artist-index tree): old logic found 0 files, new logic found 6,791 in 148 ms; the full tree scans in ~1–3 s
• Built via npm run dev and tested on local workstation. After starting it, all the symlinked *.mid files showed up in the library, when they didn't before this PR

Platforms

Found on Linux, but applies to Windows and macOS as well: the bug is in how Node's Dirent reports symlinks (neither file nor directory), which is consistent across all three platforms, and statSync/realpathSync follow links the same way everywhere. On Windows this also covers directory junctions, which Node likewise reports as symlinks.