Set USE_RGB444 for the samd51 hardware variant

[Mikey Sklar (mikeysklar)]

Follow-up to the pxt side of pxt-common-packages#1627.

That PR fixes greyscale rendering on newer PyBadge / PyBadge LC panels, and it is already live in common-packages 14.1.3 which this repo pinned in 181ee59. But the new path is gated on #ifdef USE_RGB444 and nothing defines that symbol, so it compiles out and arcade.makecode.com builds still take the RGBSET path. A user confirmed that today: comment.

This defines the flag for hw---samd51. screen.cpp already guards the path at runtime on CFG_BOOTLOADER_BOARD_ID, so the Kitronik boards that share this variant fall back to RGBSET.

Richard Knoll (@riknoll) this is the flag you offered to wire up, let me know if it belongs somewhere else in the build.

Fixes #6861

🤖 Generated with Claude Code

[Mikey Sklar (mikeysklar)]

Hardware confirmed on a PyBadge (Board-ID SAMD51J19A-PyBadge-M4, bootloader v4.0.0).

Built the colorbar demo from microsoft/pxt-common-packages#1627 locally with the flag coming only from hw---samd51, nothing set in the project's own pxt.json. Color bars render correctly. Same program built with the flag off is greyscale.

The define does reach screen.cpp: it lands in codal.json definitions, gets written to build/codal_extra_definitions.h, and that header is force-included into every pxtapp source via -include in CXX_FLAGS.

	screen.cpp.obj	UF2
flag off	7652	624640
flag on	9204	626688

626688 matches the test UF2 attached to #1627 byte for byte in size, with 66 bytes differing in the build-hash region.

One trap if anyone rebuilds this locally: the codal build does not recompile when only codal_extra_definitions.h changes, so flipping the flag and rebuilding gives you the old binary and looks like the flag does nothing. Delete build/CMakeFiles/<TARGET>.dir/pxtapp/screen---st7735/screen.cpp.obj first.