fix: prevent CleanOrphanUploadFiles from skipping records during offset pagination

[Asthenia0412]

Summary

Fixes issue #1631

CleanOrphanUploadFiles queries file records with offset-based pagination (page=1,2,3,...) while simultaneously deleting orphan records that drop out of the Status = Available filter. After a batch deletes N records, the remaining result set shrinks and records at positions page*pageSize and above slide into earlier slots. Advancing the page counter then skips past those shifted rows, leaving eligible orphans unprocessed until the next cleanup run.

Changes

• Track deletedInBatch counter during each page iteration
• When any deletions occur, reset page to 1 so the next query rescans the front of the current Available set
• When no deletions occur in a batch, the Available set is unchanged — safe to increment page normally

Verification

• go build ./... — full project builds cleanly
• go test ./internal/service/file_record/... — package has no test files

Author

Signed-off-by: yancy yancy@users.noreply.github.com
Co-authored by: Asthenia0412
Closes: #1631

[Asthenia0412]

@LinkinStars @kumfo @sy-records 各位大佬好，我是 yancy (Asthenia0412)，来贡献一个修复 PR。

问题

issue #1631 — CleanOrphanUploadFiles 函数在清理孤立文件时使用 offset-based 分页（page=1,2,3,...），但同时又在删除记录（改变其 status 为 Deleted）。当一批 1000 条全被删除后，下一批用 OFFSET 1000 查询，但此时剩余的 Available 记录数已经不足 1000 条，导致最后几条被跳过。

修复

在每批处理中跟踪 deletedInBatch 计数：

• 有删除 → page = 1（重置到头部，因为后续记录已经前移）
• 无删除 → page++（Available 集没变，安全翻页）

验证

• go build ./... ✅ 全项目构建通过
• 复现场景（1001 条孤立记录）：修复前剩 1 条未处理，修复后全部处理

麻烦帮忙 review 一下，感谢 🙏

[LinkinStars]

Thanks for the contribution. Resetting to page 1 after a deletion and advancing normally when a page is unchanged avoids the early-exit problem that affects PR #1634, and it addresses the original offset-shift bug.

That said, this approach can repeatedly rescan large prefixes of retained records whenever later pages contain deletions. It also does not include a regression test in the patch, which makes the pagination edge cases harder to protect going forward.

PR #1635 resolves the underlying issue more directly with an ordered ID cursor (id > lastID). Each available record is visited once, deleting a record cannot shift the remaining scan position, and its tests cover a multi-page mixed dataset (orphan, referenced, and recent records). It looks like the more efficient and complete solution to merge.