修复当录制记录(频道)数量太多时，界面异常卡顿，flet的cpu占用异常增高问题--本修改来自 CodeX GPT5.4 修改

[creky]

📜 标题（Title）

请提供这个Pull Request中提议的更改的简洁描述：

• 修复当录制记录(频道)数量太多时，界面异常卡顿，flet的cpu占用异常增高问题，本修改来自 CodeX GPT5.4 修改

🔍 描述（Description）

请描述这个PR做了什么/为什么这些更改是必要的：

• 录制频道太多，界面卡顿异常严重

📝 类型（Type of Change）

这个PR引入了哪种类型的更改？（请勾选所有适用的选项）

• [x ] 修复Bug
• 新功能
• 代码风格更新（格式化，局部变量）
• 重构（改进代码结构）
• 构建相关更改（依赖项，构建脚本等）
• 其他：请描述

🏗️ 测试（Testing）

请描述您已经进行的测试：

• 已经通过打flet包，在相同环境下测试，改后的界面操作非常丝滑

如果适用，请提供测试更改的说明：

📋 检查清单（Checklist）

在您创建这个PR之前，请确保以下所有框都被勾选，方法是在每个框中放置一个x：

• 我已经阅读了贡献指南文档
• 我的更改没有产生新的警告
• 我已经添加了覆盖我更改的测试
• 我已经相应地更新了文档（如果适用）
• 我遵循了这个项目的代码风格

注意： 这个PR在所有复选框被勾选之前不会被合并。

---以下来自codex的问题解析：

问题根因基本确认了，不是在录制逻辑本身，而是在 Flet 桌面 UI 层被“多卡片 + 高频整页刷新”拖住了。原来的录制列表页在列表模式下用的是 Column，卡片多时会让 Flutter 端承担很重的布局成本；同时卡片状态更新走 page.update()，会把整页一起重绘；再叠加“每张卡一个永久 duration 协程”，记录一多就会把桌面端 flet.exe 的 CPU 拉高。

我已经把修复落到 recordings_view.py 和 recording_card.py 里了。核心改动是：列表模式从 Column 改成了支持按需构建的 ListView，并去掉外层嵌套滚动；过滤、搜索、刷新这些操作改成“批量改可见性，最后统一更新一次”，不再对每张卡单独 update()；卡片状态刷新从整页 page.update() 改成单卡 card.update()；原来“每张卡一个后台任务”的时长刷新改成了一个共享循环，只更新正在录制且当前可见的卡片。这几处组合起来，能明显降低 UI diff、布局和重绘压力。顺手还修了刷新时错误操作 Container.controls 的问题，并清理了选择状态缓存，避免列表越来越乱。

我做过两层校验：一是 python -m py_compile app\ui\views\recordings_view.py app\ui\components\business\recording_card.py 已通过；二是按当前依赖 flet==0.27.6 实例化验证了 ListView/GridView 参数，避免运行时报构造参数错误。还没有替你实际拉起桌面窗口做人工滚动压测，所以最后一步建议你在大 recordings.json 数据量下直接打开录制页对比一下 CPU 和滚动流畅度。

感谢您的贡献！

[ihmily]

creky@70e8717 creky@078fc7d
creky@3a4ed96

这三个commit 请单独开分支提交pr，另外不要提交test文件夹以及多余的.idea文件夹，我会将其合并。