fix: resolve type error in history management functions

[chenxiex]

1. 读取history.json和playlists.json时进行类型守卫过滤。
2. 在去重时，仅当path字段有效才进行比较。

fix #138

[gemini-code-assist]

Code Review

This pull request refactors the history store's insertion logic by introducing validation and improved path comparison. Key changes include the addition of hasValidHistoryIdentity and hasSameNonEmptyPath helper functions to ensure data integrity and prevent duplicate entries. Feedback was provided regarding a discrepancy between the defensive use of optional chaining in the validation logic and the Track type definition, suggesting an alignment of the interface or the code to improve type safety.

[gemini-code-assist]

hasValidHistoryIdentity 函数中对 item.id 和 item.name 使用了可选链操作符（?.），这表明这两个属性可能是 null 或 undefined。然而，在 src/types/file.ts 文件中，Track 接口将 id 和 name 定义为必需的 string 类型。

这种类型定义与实际用法之间的不匹配可能会引起困惑，并掩盖潜在的问题。为了提高代码的类型安全性和可读性，建议您考虑以下方案之一：

1. 如果 id 和 name 确实可能为 null 或 undefined，请更新 Track 接口以反映这一事实。例如：

   export interface Track {
     id?: string;
     name?: string;
     // ... 其他属性
   }

2. 如果 id 和 name 保证是非空的字符串，那么可选链操作符就是多余的，可以移除：

   const hasValidHistoryIdentity = (item: Track) => Boolean(item.id.trim() || item.name.trim());

使类型定义与实际数据结构保持一致对于代码的长期可维护性至关重要。从本次修复的防御性编码来看，更新类型定义似乎是更合适的解决方案。

[nini22P]

如果对播放列表过滤，由于旧版本播放列表文件并没有id信息可能导致清空播放列表

[chenxiex]

我个人能想到的解决办法：

1. 将id设置为空字符串，就像history.json那样处理
2. 将Track设置为“id或path至少有一个存在”，然后需要id的地方做判断，实时获取id
3. 迁移的时候从delta data或者OneDrive api获取id