fix: state the verification cache's real limit instead of a claim that is false on ZFS

Run 174's Linux job failed on
ASilentlyCorruptedPackageOfTheSameSizeStillFailsAndDropsTheCache. It passed in
isolation on that same machine, and passed under full-suite load there too, so
it looked like a flake. It is not.

Measured on the runner:

    same-mtime collisions: 141 / 200
    fs type: zfs

Its /tmp is ZFS, whose timestamp granularity is coarse enough that a same-size
rewrite usually lands on the SAME last-write time. So the startup fast path —
size plus write time — cannot see that modification, and the test was right to
fail. LU1's commit message claimed "truncating or touching the package still
blocks launch"; on a coarse-timestamp filesystem the second half of that is
false. NTFS's 100 ns resolution is why it never showed on Windows.

Rather than relax the test until it passes, the contract is now stated as two
facts that are true everywhere instead of one that is not:

- A same-size corruption whose write time moves is caught at startup. The test
  moves the timestamp explicitly instead of trusting the clock, so it asserts
  the mechanism rather than the filesystem's resolution.
- A corruption preserving BOTH size and write time is NOT caught at startup and
  IS caught by a forced full verification — which is exactly what the
  launcher's Verify files button runs. New test, so the escape hatch is
  covered rather than merely mentioned.

PreparedAssetVerificationCache now documents the limit with the measurement, so
the next reader does not have to rediscover it from a red pipeline.

Verified on Windows (11 passed) and five consecutive runs on the ZFS runner
itself (11 passed each). Full solution 14,375 passed, 0 failed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/AcDream.Launcher.Core/Installation/PreparedAssetVerificationCache.cs

@@ -40,6 +40,17 @@ internal sealed record PreparedAssetVerificationEntry
 /// corrupt scratch file into a failed launch. Reads return null on anything
 /// unexpected and writes swallow IO failures, so every failure mode
 /// degrades to "hash it again".</para>
+///
+/// <para><b>What this does NOT detect.</b> A modification that preserves both
+/// the size and the last-write time is invisible here. That is not a
+/// theoretical hole — filesystem timestamp granularity varies, and on the
+/// Linux CI runner's ZFS <c>/tmp</c>, 141 of 200 measured same-size rewrites
+/// produced an identical mtime. Every ordinary corruption (a truncated
+/// download, a partial write, a disk error, any normal editor) changes one or
+/// both, and the launcher's <b>Verify files</b> action forces a full hash for
+/// the case where a user wants certainty rather than a cheap check.
+/// <c>CorruptionPreservingSizeAndWriteTimeIsCaughtOnlyByFullVerification</c>
+/// pins both halves of that contract.</para>
 /// </summary>
 internal sealed class PreparedAssetVerificationCache
 {