fix: report disk size instead of gzip transfer size

[Endika]

There was no caching bug. Correcting my own diagnosis from #31.

The panel reported 19 MB after a download and I read that as "the models are cached and the WASM is not" — 19 MB happens to match the models exactly. It does not. GitHub Pages gzips everything, and report() was summing Content-Length, which is the compressed size:

file	gzip	raw
vision_wasm_internal.js	0.08 MB	0.3 MB
vision_wasm_internal.wasm	3.32 MB	11.2 MB
hand_landmarker.task	5.61 MB	7.5 MB
pose_landmarker_lite.task	4.73 MB	5.5 MB
face_landmarker.task	3.18 MB	3.6 MB
lse-vocabulary.bin	2.26 MB	2.4 MB
total	19.17 MB	30.5 MB

19.17 MB. Everything was cached the whole time, WASM included. Two correct numbers, wrongly paired: the prose quoted the uncompressed size and the figure measured the compressed one.

What changes

The panel is titled espacio en el dispositivo, and the Cache API stores bodies decompressed, so it now measures the body rather than reading a header. That costs a pass over ~30 MB on a panel opened by hand, which is fine.

The copy gives both numbers, since both matter and for different reasons: 19 MB de descarga, 30 MB en el dispositivo. One is the data plan, the other is the phone.

One real flaw, found on the way

warm() advanced its progress counter on every attempt rather than every success, so a download where nothing was stored would still report "7 de 7". It now counts only files genuinely in the cache and throws if any failed — which is what would have told me immediately that this was never a caching problem.

The work in #31 stands on its own regardless: caching the engine explicitly is more reliable than hoping to intercept MediaPipe, and the malformed SIMD probe it fixed was a genuine bug that validated as false on every runtime.