Derive PCX plane count from the image, not the line width

[chuenchen309]

Changes proposed in this pull request:

• When decoding a multi-plane PCX scanline, PcxDecode.c recovered the
  per-plane stride by guessing the band count as state->bytes / state->xsize.
  Since state->bytes is planes * stride, that quotient is wrong whenever the
  even-padded stride differs from the width. For a width-3 RGB line it yields 4
  bands / stride 3, the plane-compaction step is skipped, and the R/G/B planes
  stay interleaved — the image decodes to the wrong colours with no error
  raised. Derive the split from the known band count (im->bands) instead.
• Add an RGB round-trip regression at a width that triggers the even-stride
  padding. The existing test_odd uses a 511×511 RGB image, whose width makes
  the guess land on the right value by luck, so it never caught this.

Scope note: at width 1 an RGB PCX still raises OSError on read — that is a
separate problem on the encoder side (it emits only two of the three colour
planes), with a different root cause, so I've left it out of this change.

---

This PR was authored by an AI coding agent (Claude Code) running on this
account: the AI found the bug (verified against the real C codec, not a
simulation), ran the repro, wrote the test, and wrote this description. The
human account holder reviews every change and is accountable for it. The
verification is real and re-runnable from the diff. If this isn't the kind of
contribution you want, say so and I'll close it.

[radarhere]

For the record, the idea was originally introduced in 5ecec7d