fix(ico): Various validity checks and error handling for corruptions

[lgritz]

1. Validity check the resolution/channels.

2. Also, in png_pvt.h's read_info(), found a spot where errors were being sent to the global error reporter instead of to the PNG reader's own error store. (It is relevant to this PR because that is called by the ICO code for certain ico files that are really using PNG encoding.)

3. Handle scanline width that's not 8 pixel multiple without running over buffer limits.

4. Guard against possible palette array overrun for 4bpp case. The 1- and 8-bpp palette cases already had computed the palette index and checked for being in range before accessing the array. But the 4-bpp case did not!

Items 1 & 2 were entirely LG. Items 3 & 4 were identified and fixed with the assistance of Claude Code / Opus 4.6 -- it was really helpful! I'm honestly not sure if it saved me 5 hours or closer to 5 minutes, but even if short, it would not have been at all fun to trace through by hand to find a subtle case that we previously forgot to check.

Assisted-by: Claude Opus 4.6 noreply@anthropic.com

[jessey-git]

There are several calculations of k inside readimg() that will all have integer overflows like those on lines 341 and 430 given sufficient widths and heights.

[lgritz]

Updated with even more protections against integer overflow.

Also updated the check_open with the knowledge that for pure ICO files (when it's not a PNG underneath), the max resolution is 256, not 64k.

AND, noticed a longstanding bug for the first time, which is that since the ICO files use a uint8 to store the resolution, it uses 0 to signify 256, which we did not handle properly before.