[r2cn] 重构 Orion 日志系统整体架构

[benjamin-747]

[任务] 重构 Orion 日志系统整体架构，并切换至新的日志处理流程

[任务分值] 40 分

[背景描述]

随着 Orion 构建系统逐步引入：
• 显式构建触发模型
• Target 级别的构建与缓存
• 重复构建（Retry / Rebuild）能力

日志系统已从「简单的输出收集」演进为 构建系统的关键基础设施，承担着：
• 构建执行过程的真实记录
• Target 级执行与缓存判断的依据
• UI / API 中构建状态与问题排查的核心数据源

然而，当前 Orion 的日志实现仍然存在以下结构性问题：
1. 架构分散、职责混杂
• 日志采集、存储、API、UI 展示强耦合
• 缺乏清晰的分层与边界
2. 难以支撑新能力
• 日志模型以“单次构建”为中心
• 对 Target 维度、缓存复用、日志继承支持不足
3. 演进成本高、风险大
• 每新增一种构建能力，都需要侵入式修改日志逻辑
• 难以做到渐进演进

[需求描述]

一、目标
• 完成 Orion 日志系统的 整体架构设计
• 明确日志在构建系统中的职责与边界
• 将现有实现 完整切换 至新的日志处理流程
• 为未来构建缓存、Target 级优化、实时日志等能力打下基础

二、核心需求

1. 日志系统整体架构设计
   完成一套清晰的日志系统架构设计，至少包含：

• 日志产生层
  • 构建执行过程
  • Target 执行单元
• 日志管理层
  • 日志标识与生命周期管理
  • 日志与 Build / Target 的关联
• 日志存储层
  • 抽象存储接口
  • Append / Read-Range 语义
• 日志访问层
  • API / UI 读取模型
  • 分段 / 按 Target 访问

2. 对外接口与兼容性处理

• 对外 API：
  • 使用新日志模型
  • 保持字段兼容或提供转换层
• UI：
  • 日志展示、滚动、分段加载正常
  • 兼容已有构建与历史日志数据（最小可用）

[代码标准]

1. 所有 PR 提交必须签署 Signed-off-by 和 使用 GPG 签名，即提交代码时（使用 git commit 命令时）至少使用 -s -S 两个参数，参考 Contributing Guide；
2. 所有 PR 提交必须通过 GitHub Actions 自动化测试，提交 PR 后请关注 GitHub Actions 结果；
3. 代码注释均需要使用英文;

[PR 提交地址] 提交到 mega 仓库的 main 分支 `` 目录；

[开发指导]

1. 认领任务参考 r2cn 开源实习计划 - 任务认领与确认;

[导师及邮箱] 请申请此题目的同学使用邮件联系导师，或加入到 R2CN Discord 后在 #p-meta 频道和导师交流。

1. Quanyi Ma genedna@gmail.com
2. Tianxing Ye yetianxing2014@gmail.com

[备注]

1. 认领实习任务的同学，必须完成测试任务和注册流程，请参考： r2cn 开源实习计划 - 测试任务 和 r2cn 开源实习计划 - 学生注册与审核

[r2cn-bot]

任务创建成功。

[AidCheng]

/request-assign

[r2cn-bot]

认领成功：等待导师审核，请及时联系导师进行审核。

[benjamin-747]

/intern-approve

[r2cn-bot]

认领审核成功：已将该任务分配给学生。