Refactor: switch to native download notification

[yasz1234]

起因：

1. 后台冻结问题：目前 Android 端部分用户使用 NoActive、Thanox 等墓碑管理工具。之前的 Flutter 通知插件生成的通知标记不规范，导致应用进入后台后无法被这些工具准确识别为“正在下载”，从而导致进程被冻结，下载中断。
2. 功能限制：原有插件方案在实现动态进度条更新时逻辑较复杂，且在部分机型上 UI 刷新频率和展示效果不理想。

改进方案：
将下载通知模块从第三方插件迁移至原生 Android 实现：

• 原生前台服务：手动实现 DownloadForegroundService 并声明 dataSync 类型。
• 标准通知 API：使用 NotificationCompat.Builder 及其 setProgress 方法实现系统级进度条。
• 双向通信：通过 MethodChannel 处理 Flutter 进度下发及原生通知动作（如暂停、跳转）的回传。

重构优势：

1. 提升后台稳定性：原生前台服务能更有效地触发系统及 NoActive 等第三方工具的豁免规则，降低应用在后台下载时被冻结或杀掉的概率。
2. 优化 UI 表现：使用系统原生进度条，UI 刷新更平滑，且符合 Android 通知栏设计规范。
3. 精简依赖：移除了 flutter_foreground_task 插件及相关冗余代码，减少了应用体积和内存占用。
4. 增强交互：优化了通知栏按钮的响应逻辑，以及点击通知跳转至下载管理页面的可靠性。

[yasz1234]

before:

after:

所有功能实现均正常

[yasz1234]

我好像进行了误操作，导致我上一个 PR 被关闭了

[Predidit]

一般来说，我们更相信已经经过大量开发者检验的插件，在没有选择的情况下才会尝试完全自己实现，因为自己的实现不可避免在初期有大量的兼容性问题

你可以确定问题来自 flutter_foreground_task 的哪部分吗，即使我们要进行相关更改，我也倾向于在 flutter_foreground_task 的基础上维护我们自己的 fork

[yasz1234]

一般来说，我们更相信已经经过大量开发者检验的插件，在没有选择的情况下才会尝试完全自己实现，因为自己的实现不可避免在初期有大量的兼容性问题

你可以确定问题来自 flutter_foreground_task 的哪部分吗，即使我们要进行相关更改，我也倾向于在 flutter_foreground_task 的基础上维护我们自己的 fork

由于 NoAcitve 和 Thanox 等 Andorid 墓碑软件是闭源且收费的，因此我们也许很难从其识别机制的源头发现问题。

我会向 NoAcitve 的作者反馈这个问题，看看能否解决。

[ErBWs]

不依赖插件其实更方便 ohos 的适配，但是好像会增加 iOS 适配的工作量