[DO0OG]

Summary

• 런처 트리거가 아닌 예열 스트림은 끝의 사다리를 만들기 직전에 표식이 있는 다른 게임을 한 번 만집니다. 기존 묶음 새로 고침 함수를 그대로 쓰고, 같은 게이트·표본 점검·디스크 대여·중지 신호를 따릅니다 (csharp/src/AsterCache.Service/Prewarm.Solar.cs, Rewarm.Ladder.cs).
• 다른 게임들과 스트림 게임을 만진 순서대로 한 묶음으로 다시 표식합니다. 스트림 게임에 이전 표식이 있든 없든 앞에 있는 양이 사다리 직후의 실제 순서와 맞습니다 (Solar.cs).
• 트리거 스트림이거나 보호하지 못한 게임은, 스트림 게임에 이전 표식이 없으면 사다리가 만진 양만큼 앞에 있는 양을 줄입니다. 이전 표식이 있으면 기존 규칙입니다 (SolarPolicy.cs).
• 스트림 도중에 뺀 양과 끝에서 줄이는 양이 겹치지 않게 했습니다.
• 보호 뒤 게이트를 다시 확인한 다음 사다리를 만듭니다.
• 보호에 쓴 양과 시간은 완료 줄의 protected K games (N MiB in S s)[, R times] 에 합산합니다.
• docs/SOLAR.md, docs/SOLAR.ko.md 에 반영했습니다.

알아 둘 점

• 근거는 설치본 로그 두 건입니다. 한 게임의 새로 고침 뒤 다른 게임의 스트림이 끝나며 사다리(8,428 MiB, 9,428 MiB)를 만들었고, 앞의 게임은 각각 8분 뒤(2551 MiB repurposed of 11056 MiB ahead)와 1분 뒤(2603 MiB repurposed of 4972 MiB ahead, 35 MiB read from disk)에 밀려났습니다.
• 사다리 직전 보호는 트리거가 아닌 예열의 끝을 표식 게임 크기만큼(약 0.5초/GiB) 늦춥니다. 짧은 스트림에서는 앞의 보호와 끝의 보호가 연달아 돌 수 있습니다. 런처 트리거 예열은 늦추지 않습니다.
• 보호하지 못한 경우의 줄이기는 보수적인 추정이라 새로 고침이 한 번 일찍 올 수 있습니다.
• 게임이 실행 중인 드라이브에서는 여전히 만지지 않습니다. 디스크에서 다시 읽을지는 여전히 재예열 점검만 정합니다.
• 이 변경의 효과는 설치본에서 아직 확인하지 않았습니다.

Test plan

• dotnet build csharp -c Release -m:1 경고 0, 오류 0
• dotnet test csharp/tests/AsterCache.Tests -c Release --no-build --filter "Category!=Live" 4,587건 통과
• dotnet format csharp --verify-no-changes 종료 코드 0
• git diff --check 종료 코드 0
• CI build-test 통과: https://github.com/DO0OG/AsterCache/actions/runs/43581387720

Closes #203