Data race: VideoReader::onReportPerformance / SequenceReader::reportPerformance read videoDecoder and decodingTime without a lock

背景

由 PR #3709 的 review（@shlzxjp）提出，属于 #3709 范围之外的既有问题，单独跟踪。

问题

• VideoReader::onReportPerformance（src/rendering/sequences/VideoReader.cpp:94-107）在不持有 locker 的情况下解引用 videoDecoder（读取 videoDecoder->isHardwareBacked()）。
• 基类 SequenceReader::reportPerformance（src/rendering/sequences/SequenceReader.cpp:33-38）也在无锁的情况下读写 decodingTime。

竞争窗口

异步解码任务（tgfx TaskGroup 线程）可在 VideoReader::onMakeBuffer 内 destroyVideoDecoder() / 重建 videoDecoder；与此同时，渲染线程在 flush 末尾经 RenderCache::recordPerformance（src/rendering/caches/RenderCache.cpp:512）→ SequenceImageQueue::reportPerformance → SequenceReader::reportPerformance → VideoReader::onReportPerformance 走到同一路径，形成对 videoDecoder 与 decodingTime 的无锁并发读写。

与 #3709 的关系

#3709 为析构路径加锁，缓解了「析构 vs onMakeBuffer」一侧的风险，但上述 reportPerformance 读写竞争与析构锁无关，仍然存在。

建议

评估在 onReportPerformance / reportPerformance 读写 videoDecoder 和 decodingTime 时补充与 onMakeBuffer 一致的加锁保护，或改用原子/快照方式规避竞争。

Read VideoReader.cpp at onReportPerformance and onMakeBuffer, then trace SequenceReader.cpp, RenderCache.cpp, and SequenceImageQueue::reportPerformance. Compare the existing locking around decoder changes with the performance-reporting reads and writes. Done means videoDecoder and decodingTime are accessed safely across these threads, with the relevant race no longer reproducible.