fix(turn-tail): leave a turn that declared deliveries to the delivery card

[longisland-icetea]

问题

同一轮里既改代码又交付图片时，交付卡片整个消失。 例如脚本出图后 present 它、顺手还改了脚本或文档——这是最常见的收尾方式——那个 present 出来的图片不会出现在这一轮的交付列表里。

根因在两份数据不一致：

• conversation.chat.turnTail 是 chain 槽，选举是先命中先赢 + break（ui-renderer spec.kind === 'chain' 分支）。本插件只要这一轮有写文件就抢占这个位置，官方交付卡片的注册者根本轮不到被咨询；
• 本插件的 chips 只读 produced（用户级即「本次产出」行，由 write / edit 类工具的改动路径累积），而脚本产出的图片这类文件是 present 声明的，只进 presented、不进 produced。

于是抢占之后这一轮只剩产出行，presented 无处渲染。官方卡片本来把两者一起渲染（selectDeliverables 返回 { produced, presented }），所以这些交付不是没数据，是被本插件挡掉了。

修法

这一轮在收尾回复前声明过交付时，本插件主动退让：selectProducedFiles 返回 null，把位置还给官方卡片。判据与官方 presentedForClosing 一致（存在 presented.seq < 收尾 seq 的声明）——晚于收尾回复的声明本来也渲染不出卡片，不影响抢占。

这与已有的两个退让分支（editor tab 被设置禁用、侧栏被外部禁用）是同一条路径：官方卡片就是宿主预期行为，不是能力损失。

不改成「本插件自己把 presented 也画出来」：那要自己接管交付卡片的打开通道（presentedFileUrl 认证打开、原生「用默认应用打开」菜单、桌面可用性判定），面比让位大得多，且与宿主实现长期重复。

验证

tests/produced-files.spec.ts 新增用例，覆盖四种情形（有先前声明 → null；空声明 / 晚于收尾的声明 / 无 presented 字段 → 仍抢占）。

已实测反事实：把该用例跑在本 PR 之前的 selectProducedFiles（base blob 23a2f1ea）上失败——返回 ['a.ts']，即抢占发生、presented 被挡掉；打上补丁后通过。pnpm typecheck 通过。

代价

这类轮次的「本次产出」标签回到宿主行为：点开走宿主文件预览，不再是本插件的侧栏编辑器；「在文件夹中显示」也不再提供。其余轮次（仅改文件、仅交付）行为一字不变。

另外记录一条未处理项：priority: -1 在 chain 语义下不生效（选举不看 priority），本 PR 未改动。