chore(icons): committed .jpg/.png files contain WebP bytes — extension/MIME mismatch

[jacuzzicoding]

Summary

Several committed icon files under public/icons/<category>/ carry .jpg or .png extensions but actually contain WebP bytes (RIFF...WEBP magic header). This was inherited from the v0.9.1 wiki scrape — the resolver wrote whatever extension Fandom served, but the underlying bytes were sometimes WebP regardless. Manifest then advertises the wrong type, and CDN-served Content-Type headers match the (incorrect) extension.

Why it works today

Browsers sniff content type from the magic bytes, not the URL extension or Content-Type header. So images render correctly despite the mismatch. This is a correctness-adjacent issue: the manifest lies about the format, which affects:

• Future tooling that trusts the manifest's declared extension
• Image-optimization pipelines that key on extension
• Strict CDN configurations that refuse to serve format mismatches

Fix sketch

1. Scan public/icons/<category>/* for files where the magic bytes don't match the extension.
2. For each mismatch:
   • Rename to the correct extension (.webp, .png, .jpg per actual content)
   • Or re-encode to a single canonical format (e.g. PNG via sharp) for consistency
3. Regenerate public/icons/manifest.json to reflect the corrected extensions.
4. If keeping .webp: confirm the <ItemIcon> resolver and any consumers handle WebP correctly (they should — modern browsers all support it).

Out of scope

• Re-running scrapers.
• Changing render behavior in <ItemIcon>.

Acceptance criteria

• Every file in public/icons/<category>/ has an extension that matches its magic bytes.
• Manifest entries reflect actual file extensions.
• Tests still pass and icons still render in dev preview.

References

• Surfaced by Copilot review on PR #94, comment r3188656992.