[DO0OG]

Summary

• 캐시 다시 만지기(묶음 다시 만지기, 사다리, 새로 고침)가 스파스 속성 파일의 범위를 건너뜁니다. 매핑을 만들기 전에 파일 속성(메타데이터)만 조회하며, 한 번의 실행에서 파일마다 한 번 조회합니다 (csharp/src/AsterCache.Windows/StandbyTouch.cs, FileGuards.cs).
• 건너뛴 양은 만진 양·오류·디스크 읽기와 따로 세고(TouchResult.SkippedBytes), 로그 줄 끝에 , K MiB in sparse files not touched 로 남깁니다. 예열 완료 줄은 requeued N MiB in S s (K MiB in sparse files not touched) 가 됩니다. 건너뛴 양이 0 이면 로그는 이전과 같습니다 (Solar.cs, StreamRequeue.cs).
• 목록 전체가 스파스 파일이라 만질 것이 없는 게임은 ladder has nothing to touch (…) 를 남기고, 그 판정을 기억해 재예열 점검마다 다시 시도하지 않습니다. 그 게임의 새 예열 스트림 뒤에는 다시 판정합니다 (Solar.cs, Rewarm.Ladder.cs).
• 사다리가 멈춘 줄(after T of N MiB)의 N 을 사다리 전체로 고정했습니다.
• docs/SOLAR.md, docs/SOLAR.ko.md 의 로그 설명과 한계 절에 반영했습니다.

알아 둘 점

• 근거는 세 가지입니다. 같은 PC 의 HDD 에서 시험 파일로 잰 값(일반 파일은 예열 읽기 직후 새 매핑으로 만져도 디스크를 읽지 않았고 47회, 스파스 속성 파일은 매번 64 MiB 를 약 1.1초에 다시 읽음), 설치본 로그(묶음 다시 만지기가 서로 다른 스트림에서 같은 위치 3,379 MiB 에서 requeue stopped by disk reads 로 멈추고 재예열이 되풀이됨), 파일 속성 집계(해당 게임 폴더의 .xsub 210개 중 78개, 50.6 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,473건 통과
• StandbyTouchLiveTests 5건 통과 (스파스 속성을 준 실제 임시 파일 포함)
• dotnet format csharp --verify-no-changes 종료 코드 0
• git diff --check 종료 코드 0
• CI build-test 통과: https://github.com/DO0OG/AsterCache/actions/runs/43537751446

Closes #191