[DO0OG]

Summary

• 예산 계산(WarmBudget)이 쓰는 게임별 추정값(전체 크기, 관찰량)을 재사용합니다. 입력 파일(계획, 목록, 예열 전용 목록, volatile, 원시·boot 기록)의 존재·길이·수정 시각과 관련 게임 설정이 같고 10분 이내이면 다시 계산하지 않습니다 (csharp/src/AsterCache.Service/WarmEstimateCache.cs, Prewarm.Memory.cs).
• 보충이 "읽을지 기다릴지"를 정하는 판정은 추정값으로 하고, 읽기로 정해진 뒤 읽기 직전에만 계획을 새로 읽습니다. 새 값이 추정과 다르면 그 값을 기억하고 이번 회는 읽지 않으며, 다음 회가 새 값으로 판정합니다 (Prewarm.Supplement.cs).
• 예열이 실제로 읽을 범위를 정하는 계획 읽기(스트림, 보충, 서비스 시작)는 이전처럼 매번 새로 읽습니다.
• 입력 파일 서명을 만드는 코드를 기존 InputStamp 와 한 곳으로 모았습니다. InputStamp 의 값은 이전과 같습니다 (Streaming.cs).
• 등록에서 빠진 게임의 추정값은 지웁니다 (Prewarm.Games.cs).

알아 둘 점

• 고치기 전 설치본에서 잰 값: 부분 예열 게임이 있는 유휴 상태에서 450초 동안 CPU 100.7초, 읽기 1,468 MiB, 30초마다 3~5초 몰림. 고친 뒤의 설치본 값은 아직 재지 않았습니다.
• 같은 입력에서 예산 계산의 결과(배정, 건너뜀, 순위)는 이전과 같습니다. 달라지는 경우는 계획 계열 파일은 그대로인데 게임 갱신으로 목록의 게임 파일 크기가 바뀐 때이며, 추정값이 최대 10분 늦게 바뀝니다. 실제 읽기 목록은 매번 새로 만들므로 더 읽지는 않습니다.
• 예산 배정값은 보충·사다리·대기 재시도에서 읽을 양의 상한으로도 쓰이므로, 위 경우 상한도 최대 10분 늦게 바뀝니다.
• 목록이 커진 채 기다리기만 하는 회에는 부분 예열 상태의 전체 크기 표시(partial X/Y, 상태의 hot_mib, 플레이 기록의 start warm X/Y 의 Y)가 다음 실제 읽기 때까지 이전 값으로 남습니다. 판정과 읽는 양에는 영향이 없습니다.
• 추정과 새 값이 다른 드문 회에는 읽기가 한 보충 주기 늦어지고, 그 회의 재예열 점검이 보충 대신 사다리 만지기나 읽은 부분의 재예열을 한 번 할 수 있습니다.
• 메모리 예비량, 캐시 예산, 안티치트 게이트, 로그 문구는 바뀌지 않았습니다. 새 로그 줄은 없습니다.

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

Closes #189