来自 #112 的架构级评审建议。不阻塞合入，仅供参考是否有更好的架构解法。
💡 [建议 · schema] storage/istorage/IWal.go:1
问题根因：接口 IWal 被删除，但 istorage.LogEntry 结构体保留（因 SSTable 共用）。如果将来引入新的 WAL 实现（例如基于 Raft 日志的本地缓存 WAL），需要重新定义接口。当前清理后，istorage 包中无任何 WAL 相关契约，属于合理清理，但建议确认 LogEntry 的归属包是否合适——它同时服务于 WAL（已删除）和 SSTable，也许应移入更中立的包。
为什么低级解法不够：不做改动目前也没问题，LogEntry 的当前位置对现有代码无害。
架构级方案：评估是否将 istorage.LogEntry 重命名为 SSTableEntry 或移入 zstorage 包（仅被 SSTable 和 MemTable 的 collectAllEntry 使用）。这不是当前阻塞问题，而是长期代码组织建议。
代价/收益：重构代价低，收益是语义更精确；但可能影响其他正在引用 istorage.LogEntry 的模块（如有），需确认调用方。
💡 [建议 · schema]
storage/istorage/IWal.go:1问题根因：接口
IWal被删除，但istorage.LogEntry结构体保留（因 SSTable 共用）。如果将来引入新的 WAL 实现（例如基于 Raft 日志的本地缓存 WAL），需要重新定义接口。当前清理后，istorage包中无任何 WAL 相关契约，属于合理清理，但建议确认LogEntry的归属包是否合适——它同时服务于 WAL（已删除）和 SSTable，也许应移入更中立的包。为什么低级解法不够：不做改动目前也没问题，LogEntry 的当前位置对现有代码无害。
架构级方案：评估是否将
istorage.LogEntry重命名为SSTableEntry或移入zstorage包（仅被 SSTable 和 MemTable 的collectAllEntry使用）。这不是当前阻塞问题，而是长期代码组织建议。代价/收益：重构代价低，收益是语义更精确；但可能影响其他正在引用
istorage.LogEntry的模块（如有），需确认调用方。