PNG upload regression test

The shared uploader now checks PNG chunk boundaries without converting a large byte array into function arguments. Animated images and files whose animation status cannot be inspected are uploaded unchanged. Proven static images still use optional cover resizing. This fix was verified on testing before promotion to main; existing production cover rendering remains intact.

Generate the same valid images used by the automated regression tests (from the repository root):

pnpm --filter @yumina/app exec tsx ../../scripts/generate-upload-test-assets.ts ../../.tmp/upload-test-assets

Both files are 512 × 512 pixels. The static PNG is approximately 769 KiB; the APNG is approximately 1.50 MiB. Their genuine image data deliberately exceeds the old 256 KiB header-inspection limit. No personal data or external resources are embedded.

1. Open the testing site and refresh to load the new version.
2. In Library → Assets, upload large-static-upload-test.png. A blue checkerboard should appear without an “Upload failed” message. Refresh and confirm it remains in the library.
3. Upload animated-upload-test.png. It should alternate between blue and orange checkerboards once per second wherever the original asset is displayed. Open/download the original if a thumbnail is static, and verify the animation there.
4. Try the files as a card cover. Saving should succeed; the animated upload must retain its frames. Static card thumbnails alone are not proof that the original animation was lost.
5. Optionally repeat the library upload on mobile and try a batch containing both files.

Automated coverage includes large PNG/APNG upload stages, metadata containing misleading chunk names, bounded/truncated/unreadable headers, GIF/JPEG/WebP, original-byte preservation, static resizing, and existing storage-timeout/registration failures. A mocked canvas verifies that animations and unknown headers never enter the resizing path. The new tests reproduce RangeError: Maximum call stack size exceeded against the original production detector.

No database migration is required. Main uses the same bounded detector and original-file preservation verified on testing. Existing creator upload controls and navigation are unchanged, so no onboarding copy or lesson revision is needed.