Validate RGBMatrix arguments before reserving a display bus

[ladyada-eagleclaw]

When an RGBMatrix constructor receives an invalid height (for example, height=32 with five address pins), it currently reserves a display-bus slot before raising ValueError. A second attempt then fails with "Too many display busses", and reset handling can encounter the incomplete object.

Run the existing binding validations first, then allocate/register the object immediately before common-hal construction. This changes one file, with five added lines and two removed lines.

Fixes #9674.

Validation

AI-assisted: Codex audited the reported failure and previous review history, prepared the minimal change, and checked compiler output and actual MatrixPortal S3 serial results.

• Full MatrixPortal S3 firmware build against current main 6fefe633d1 and its pinned Protomatter dependency passed.
• On the attached S3, the baseline produced ValueError, then RuntimeError: Too many display busses for each of five cases: height mismatch, bit_depth=0, width=0, tile=0, and five RGB pins.
• With this change, both attempts produce the expected ValueError in all five cases. A valid 64x64 constructor afterward succeeds, and an unrelated caught NameError also succeeds.
• The hardware test used one-bit depth, explicitly released displays between cases, and verified a 4096-element framebuffer. No soft reset with an incomplete baseline object was needed.
• Applicable pre-commit hooks and git diff --check passed.

Scope: this fixes errors from the existing binding argument checks. Exceptions arising later from common-hal pin preflight or memory allocation are outside this change.

[tannewt]

Thank you!