fix: prevent document processing cleanup from using expired context

[HelloWeit]

背景

文档处理任务在 embedding/indexing 阶段可能因为任务超时或上游服务超时而失败。此前 document:process 任务依赖 Asynq 默认 30 分钟超时，大文件场景下任务尚未处理完成就可能触发 context deadline exceeded。相关超时时间配置问题已在前一个 PR fix: extend document processing timeout for large files 中处理。

本 PR 关注失败后的收尾逻辑：processChunks 在失败后会尝试把 knowledge 标记为 failed，并清理 chunks/index。

当前失败收尾继续使用原始任务 ctx。当失败原因是 context deadline exceeded 时，这个 ctx 已经被被取消，后续的状态更新和清理失败，导致 knowledge 仍然停留在 processing，前端页面看起来像任务一直没有结束。

// 重试第三次后，由于文件较大，没有解析完成，在batchIndex函数中失败，进入清理流程，但是CTX是无效的，导致清理失败。
INFO [2026-05-14 19:02:57.030] [document_process=edd69759-ad06-4e65-a44f-4b3e6b637a79] knowledge_process.go:1867[ProcessDocument] | Processing document task: knowledge_id=edd69759-ad06-4e65-a44f-4b3e6b637a79, file_path=local://10000/edd69759-ad06-4e65-a44f-4b3e6b637a79/1778751019016040301.xlsx, retry=3/3

ERROR[2026-05-14 19:32:57.021] [document_process=edd69759-ad06-4e65-a44f-4b3e6b637a79] knowledge_process.go:531[processChunks] | Delete index failed: context deadline exceeded

修改内容

• 为文档处理失败收尾增加独立的、有限时长的 cleanup context。
• cleanup context 保留必要的 tenant 信息，确保 chunks/index 清理仍然按租户执行。
• 使用 cleanup context 更新 parse_status=failed 和 error_message。
• 使用 cleanup context 执行 best-effort chunks/index cleanup。
• 显式记录失败状态更新或清理失败日志。
• 不改变原有文档处理、embedding/indexing、Asynq retry 语义。

测试

已执行：

gofmt -w internal/application/service/knowledge_process.go
go test ./internal/application/service/... ./internal/router/...

说明：

与该修改直接相关的代码已通过 gofmt。
如本地未启动 Elasticsearch、OSS 等外部依赖，部分现有测试可能失败，失败原因与本次修改无关。

手动验证：

将文档处理 timeout 临时调小，用大文件/慢 embedding 服务触发 BatchIndex 超时。
超时后确认 knowledge 能从 processing 更新为 failed。
确认失败收尾使用新的 cleanup context，状态更新和 chunks/index 清理不会因为原始任务 ctx 已取消而立即失败。

代码上是在 knowledge_process.go 的 processChunks 失败分支里改，不需要动页面，也不需要动队列配置。这个 PR 和前一个 timeout 配置 PR 是互补的：前一个减少“大文件被 30 分钟打断”的概率，这个保证“即使真的超时失败，失败状态和清理也尽量能落库”。