[DO0OG]

Summary

• 표식이 있는 게임을 한 묶음으로 다룹니다. 지금 만질 수 있는 게임 중 하나라도 새로 고칠 때가 되면 묶음 전체를 순위가 낮은 게임부터 차례로 새로 고칩니다. 게이트에 막힌 게임은 묶음을 시작시키지 않고 건너뜁니다 (csharp/src/AsterCache.Service/Rewarm.Ladder.cs, Solar.cs).
• "앞에 있는 양"을 만진 순서에 맞게 다시 계산합니다(A_i = max(0, C − Σ_{j≥i} t_j)). 내 표식보다 먼저 표식을 받은 다른 게임이 다시 만져지면 그 게임이 이전에 만진 양과 이번에 만진 양 중 작은 쪽만큼 줄입니다 (SolarPolicy.cs).
• 런처 트리거가 아닌 예열 스트림(서비스 시작, 재예열, 보충)은 디스크를 읽기 전에 표식이 있는 다른 게임을 먼저 만집니다. 완료 줄 끝에 , protected K games (N MiB in S s) 로 남습니다 (Prewarm.Solar.cs, Prewarm.Run.cs).
• 새로 고칠 때의 판정에 "남은 여유가 2 GiB 보다 작음"을 더했습니다. 표식 때 이미 앞에 있는 양이 4 GiB 보다 작던 게임에는 적용하지 않고, 묶음 새로 고침 사이는 60초 이상 둡니다.
• 한도로 마무리한 스트림도 읽은 창과 같은 계획으로 범위를 확정할 수 있으면 끝난 직후 사다리를 만듭니다. 틈 메우기 계획으로 읽은 경우 등은 이전처럼 재예열 점검에 맡깁니다.
• 읽기 대여를 얻지 못한 게임은 표식을 지우지 않고 그 회만 건너뜁니다.
• 로그 꼬리(스파스 관련 두 가지, protected, requeued)는 MiB 로 0 이면 붙이지 않습니다.
• docs/SOLAR.md, docs/SOLAR.ko.md 에 판정과 실험 값을 반영했습니다.

알아 둘 점

• 근거는 설치본 로그와 같은 PC 의 실제 가동 환경에서 시험 파일 4개를 61분 추적한 실험입니다. 다시 만지지 않은 세 파일은 함께 사라졌고 한 번 더 만진 파일은 39분을 더 남았습니다. 서비스가 다른 게임을 새로 고치자 앞에 있던 양이 12.4 GiB 에서 약 5.9 GiB 로 줄었고, 30초에 약 1.9 GiB 의 재사용이 몰린 구간이 두 번 있었습니다.
• 이 변경의 효과(여러 게임이 함께 유지되는지)는 설치본에서 아직 확인하지 않았습니다.
• 스트림 앞의 보호는 서비스 시작·재예열·보충 스트림의 시작을 표식 게임 크기만큼(약 0.5초/GiB) 늦춥니다. 런처 트리거 예열은 늦추지 않습니다. 보호에 쓴 시간은 yielded 와 디스크 노출 시간에서 뺍니다.
• 다른 프로그램이 앞쪽 페이지를 다시 참조해 뒤로 보내는 것은 셀 수 없어 기준이 늦을 수 있고, 그 경우는 이전처럼 재예열 점검이 받칩니다. 가용 메모리가 모든 게임을 담지 못하면 순위가 낮은 게임부터 밀려나는 것은 그대로입니다.
• 읽기 대여를 확인한 뒤 표본을 읽기 전에 대여를 잃는 드문 경우에는 이전처럼 표식이 지워지고, 다음 재예열 점검이 사다리를 다시 만듭니다.
• 디스크에서 다시 읽을지는 여전히 재예열 점검만 정합니다. 읽는 양과 순서, 트리거 선점, 메모리 예비량, 캐시 예산, 안티치트 게이트, 설정 파일 형식은 바뀌지 않았습니다.

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,525건 통과
• dotnet format csharp --verify-no-changes 종료 코드 0
• git diff --check 종료 코드 0
• CI build-test 통과: https://github.com/DO0OG/AsterCache/actions/runs/43562124520

Closes #195