[DO0OG]

Summary

• 예열 스트림이 스파스 속성 파일의 범위를 매핑 없이 버퍼드 읽기로 읽습니다. 묶음의 범위 목록을 스파스 여부가 같은 연속 구간으로 나눠 원래 순서대로 처리하며, 스파스가 아닌 파일은 이전과 같습니다 (csharp/src/AsterCache.Prefetch/ZoneStreamer.cs).
• 스파스 구간의 읽기는 앞읽기를 끄는 플래그로 엽니다. 다른 버퍼드 읽기 호출부는 그대로입니다.
• 버퍼드 읽기로 읽은 양을 통계(StreamStats.BufferedBytes)에 더하고, 예열 완료 줄 끝에 , K MiB of sparse files by buffered read 로 남깁니다. 0 이면 붙지 않습니다.
• 고정은 스파스 파일을 건너뜁니다 (csharp/src/AsterCache.Windows/FilePin.cs).
• 스파스 판정을 FileGuards.IsSparse 한 곳으로 모아 다시 만지기와 함께 씁니다.
• docs/DEVELOPMENT, docs/SOLAR, docs/AUTO_MODE, docs/CONFIGURATION 의 영문·한국어 문서에 반영했습니다.

알아 둘 점

• 근거는 같은 PC 의 HDD 에서 시험 파일로 잰 값입니다. 스파스 속성 파일은 매핑을 만들고 닫기만 해도 앞서 올린 범위가 캐시에서 버려졌고(3회 모두), 묶음마다 새 매핑으로 세 범위를 차례로 읽으면 마지막 범위만 남았습니다(6회 모두). 일반 파일은 모두 남았습니다. 버퍼드 읽기만 쓰면 캐시가 이어졌습니다(28회 중 27회).
• 앞읽기를 켠 버퍼드 읽기는 흩어진 256 MiB 요청에 13~23% 를 더 읽었고, 끄면 1.2% 이하였습니다. 재읽기는 12회 모두 캐시에서 읽혔습니다. 처리량은 회마다 편차가 커서 "느려지지 않았다"까지만 말할 수 있습니다.
• 같은 시험에서 흩어진 스파스 목록의 버퍼드 읽기는 초당 91.3 MiB, 일반 파일의 매핑 읽기는 116.0 MiB 였습니다. 스파스 파일의 첫 예열은 그만큼 느릴 수 있습니다.
• 실제 게임과 설치본에서의 효과는 아직 재지 않았습니다.
• 버퍼드 읽기는 오류를 범위마다 셉니다(매핑 읽기는 파일마다 한 번). 런처가 파일에 바이트 범위 잠금을 걸면 그 범위가 오류로 세어져 마무리·보충 판정이 달라질 수 있습니다. 그런 런처가 있는지는 확인하지 않았습니다.
• 게임 파일의 속성은 읽기만 하고 바꾸지 않습니다. 판정은 파일 속성으로만 하며 게임 이름이나 확장자를 보지 않습니다. 읽는 범위와 순서, 묶음 사이 점검, 메모리 예비량, 캐시 예산, 안티치트 게이트는 바뀌지 않았습니다.

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,487건 통과
• Live 시험: 스파스 속성을 준 실제 임시 파일에서 두 범위를 차례로 읽은 뒤 첫 범위가 캐시에 남음 (이전 읽기 방식으로 바꾸면 3회 모두 실패)
• dotnet format csharp --verify-no-changes 종료 코드 0
• git diff --check 종료 코드 0
• CI build-test 통과: https://github.com/DO0OG/AsterCache/actions/runs/43546980688

Closes #193