Fix stale sha256/size records and dead or mis-pointed model links

[nuri-yoo]

Follow-up to #509, as requested there. This started as the group-3 fix, but after more digging it now corrects all 8 records from the issue, the dead 2x-Fallin-Soft link, and the dead 4x-Remacri mirrors from #474. Every sha256/size below was re-verified against the currently served files on 2026-08-03 via curl -sL <url> | shasum -a 256; npm run validate-db and npm test pass locally.

1x-UnResizeOnly-RCAN, 4x-PBRify-UpscalerV4 — assets replaced in place (group 3)

The URLs are unchanged; the recorded sha256/size are updated to the served files. Both served files are zip-based torch checkpoints (PK magic, data.pkl member), so type is corrected from safetensors to pth as well.

entry	served sha256	served size
1x-UnResizeOnly-RCAN	c3f3041a…	31,259,352
4x-PBRify-UpscalerV4	82db39e3…	140,345,646

2x-Fallin-Strong, 2x-Fallin-Soft — release is ONNX-only, links were dead or ambiguous (group 3, #496)

#501 moved Strong's URL from a dead Mega link to the release tag page but kept the Mega-era hash, and Soft still points at the dead Mega link reported in #496. The Fallin release serves exactly four ONNX assets (soft/strong, each as fp16 and fp32), so each entry now lists its own fp16 and fp32 assets as two resources with direct asset URLs and verified hashes — the same shape as 2x-GameUpV2-TSCUNet. Direct URLs also remove the tag-page ambiguity that let these records drift unnoticed (one page hosting two model families).

1x-SuperScale family — the recorded hash never matched any released asset (group 1)

The three entries shared one sha256/size (f5844dd7… / 1,195,070) that appears nowhere else in the database and matches none of the release's assets. Per the GitHub API, the assets were never replaced after upload (each asset's updated_at equals the release's publish time), so the shared value was wrong from day one — presumably the hash of a pre-upload local build. Each entry's URL already names its intended file, so the records are updated to what those URLs serve. To rule out mixed-up files, I checked the tensor names in each safetensors header: the SPAN entry's file has SPAN's block_1.c1_r.* layout, and both RPLKSR entries' files have RealPLKSR's feats.*.channel_mixer.* layout, matching each entry's architecture field.

entry	served sha256	served size
1x-SuperScale	703e4973…	8,888,072
1x-SuperScale-RPLKSR-S	8620aa99…	9,395,932
1x-SuperScale-Alt-RPLKSR-S	7fd6ba24…	9,395,932

1xSPANGELION — both entries pointed at the wrong sibling file (group 2)

The repo's 1xSPANGELION/ folder holds three model files: the base 1xSPANGELION.pth plus 1xSPANGELION_SHARP.pth and 1xSPANGELION_INTERPOLATED.pth. The served _SHARP file hashes to exactly the SHARP entry's recorded sha256/size (1fe9b52d… / 8,938,861), and the served _INTERPOLATED file to exactly the INTERPOLATED entry's (0c5650f0… / 8,944,458). So the recorded hashes were correct all along — both entries just pointed at the base file. Only the URL filenames change; sha256/size stay as recorded.

4x-Remacri — both mirrors dead or flaky (#474)

The Google Drive link 404s, and the pcloud free link is traffic-gated (dead in #474's screenshots, resolving again today). The FacehugmanIII/4x_foolhardy_Remacri Hugging Face copy serves the byte-identical file — sha256/size equal the recorded values exactly, and so does the pcloud original when it's reachable (both downloaded and hashed today). The Hugging Face URL becomes the primary link, the dead Google Drive link is dropped, and the pcloud link stays as a mirror. sha256/size unchanged.

Closes #509. Closes #496. Closes #474.