[DO0OG]

Summary

• 캐시 새로 고침(메모리 안에서만 만지기)이 드라이브 사용량 게이트를 따르지 않습니다. 게임 실행, 같은 드라이브의 게임 실행, 종료 직후, 예산 게이트는 그대로이고, 재예열 점검처럼 디스크를 읽을 수 있는 경로의 게이트도 그대로입니다 (csharp/src/AsterCache.Service/Rewarm.cs, Rewarm.Ladder.cs).
• 드라이브가 바쁠 때 표본이 식게 나오면 한 표식에서 한 번만 표식을 두고 건너뛰고, 두 번째에는 이전처럼 표식을 지우고 재예열 점검에 맡깁니다 (Solar.cs).
• 런처 트리거가 아닌 예열 스트림은 묶음 사이에서 때가 되면 표식이 있는 다른 게임을 다시 만집니다. 통계 조회는 10초 간격이고 묶음 새로 고침의 최소 간격 60초를 따릅니다. 완료 줄의 protected K games (N MiB in S s) 에 합산하고 여러 번이면 , R times 를 붙입니다 (Prewarm.Solar.cs, Prewarm.Run.cs).
• 스트림 도중에 다시 표식할 때는 그 스트림이 그때까지 만진 양을 빼고 앞에 있는 양을 계산합니다 (SolarPolicy.cs).
• 서비스 시작 때 prewarm skipped (already warm) [service start] 로 건너뛴 게임은 표본을 다시 읽지 않고 곧바로 사다리를 만듭니다 (Prewarm.Startup.cs).
• 표식이 있던 게임의 식음·건너뜀·빠짐 로그 줄 끝에 , since the ladder M min ago: R MiB repurposed of A MiB ahead 를 덧붙입니다.
• docs/SOLAR.md, docs/SOLAR.ko.md 에 반영했습니다.

알아 둘 점

• 근거는 설치본 로그입니다. 사다리 완료 3분 뒤 꼬리가 빠졌고 그동안 약 4 GiB 가 재사용됐는데 다른 프로세스가 같은 드라이브를 쓰고 있어 새로 고침이 돌지 못했습니다. 8분짜리 보충 스트림 직후에는 시작 직전에 만져 둔 다른 게임이 식었습니다(표본 8곳 중 6곳). 서비스 재시작 뒤 10분 안에 한 게임이 식고 다른 게임의 꼬리가 빠진 일이 두 번 있었습니다.
• 게임이 실행 중인 드라이브에서는 여전히 만지지 않습니다. 디스크에서 다시 읽을지는 여전히 재예열 점검만 정합니다.
• 드라이브가 바쁠 때 새로 고침이 캐시에 없는 부분을 만나면 표본 8 MiB 와 멈추기 전까지 최대 약 100 MiB 가 디스크에서 읽힐 수 있습니다.
• 스트림 도중의 보호와 서비스 시작 사다리는 스트림과 시작 예열을 표식 게임 크기만큼(약 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,557건 통과
• dotnet format csharp --verify-no-changes 종료 코드 0
• git diff --check 종료 코드 0
• CI build-test 통과: https://github.com/DO0OG/AsterCache/actions/runs/43573691010

Closes #199