Fix Settings crash from duplicate template identities

[ZekeAranyLucas]

Summary

Fix a fatal duplicate-key assertion when opening Settings with the home directory listed as a recent project. Settings previously loaded the same personal template files as both project and home templates, then passed their repeated UUIDs to Dictionary(uniqueKeysWithValues:).

Changes

• Extract Settings template loading into a testable SettingsTemplateEntry model.
• Deduplicate canonical directories and file paths, preserving the personal origin when a project points at the home template directory.
• Identify Settings rows and editor selections by file path instead of template UUID. Distinct files sharing a UUID remain independently editable and deletable, with existing usage-count behavior preserved.
• Add seven regression tests covering the home-directory case, repeated and symlinked paths, shared UUIDs, editing/deletion, and empty libraries.

Test plan

• Confirmed the home-project regression triggers the original fatal duplicate-key assertion before the fix.
• Passed all 35 tests in SettingsTemplateEntryTests, TemplateStorageTests, TemplateUsageTests, and TemplateEditingTests.
• Built the native macOS app and invoked its actual Settings menu in an isolated fixture with 11 personal templates, the home directory as a project, and two project copies sharing a template UUID. Settings opens and reopens successfully.
• Passed strict SwiftLint and Swift Format checks on all changed Swift files, plus git diff --check.
• Validation used a separate app identity and support directory; no installed app, live sessions, or personal template files were modified.

Checklist

• I have read the Contributing Guidelines
• I have signed off my commits (git commit -s) per the DCO
• Tests pass locally (make test) - targeted suites above passed; the full suite was not run.
• Code follows the existing style (make check) - strict lint and formatting checks passed for the changed files; the full repository check was not run.