feat(q5_max): enable Keychron RGB and fix EEPROM persistence

Enable KEYCHRON_RGB_ENABLE for the Q5 Max, wiring up PER_KEY_RGB and
MIXED_RGB effects, and fix a cascade of EEPROM bugs that caused the
Launcher-configured RGB mode to revert to the default heatmap on every
power cycle and wireless transport change.

Keychron RGB enablement:
- Add KEYCHRON_RGB_ENABLE = yes to rules.mk
- Define default_per_key_led[] and default_region[] for the ANSI Encoder
  layout in ansi_encoder.c (extern'd by keychron_rgb.c)
- Fix missing #include "eeconfig_custom_rgb.h" in mixed_rgb.c and
  rgb_matrix_kb.inc so EECONFIG_SIZE_CUSTOM_RGB is in scope for the
  compile guards that gate the custom effects
- Add #undef EECONFIG_KB_DATA_SIZE before the Keychron redefinition in
  eeconfig_kb.h to suppress redefinition of QMK's default-zero value

EEPROM persistence fixes (keychron_rgb.c):
- Fix retail_demo_enable never being written to EEPROM in
  eeconfig_reset_custom_rgb(): original code used eeprom_read_block
  instead of eeprom_update_block, leaving 0xFF on freshly-flashed
  boards; retail_demo_task() treats any non-zero value as "demo active"
  and forces the mode to CUSTOM_MIXED_RGB every scan
- Clamp retail_demo_enable > 1 to 0 on load to recover boards already
  affected by the above bug
- Move EECONFIG_KEYBOARD version stamp from eeconfig_init_custom_rgb()
  (load path) to eeconfig_reset_custom_rgb() (reset/write path) so the
  version is only stamped when valid defaults are actually written
- Call eeconfig_update_rgb_matrix() in kc_rgb_save() so the current QMK
  RGB mode is persisted alongside Keychron data; without this,
  rgb_matrix_init() (called on every transport change) reloads the
  compile-time default RGB_MATRIX_TYPING_HEATMAP from EEPROM

Transport-change persistence (q5_max.c):
- Call eeconfig_init_custom_rgb() in keyboard_post_init_kb() so Keychron
  RGB arrays are loaded from EEPROM on every boot instead of being
  zero-initialised
- Add wireless_enter_connected_kb() hook: re-applies the EEPROM-saved
  QMK RGB mode after BT/2.4G reconnect in case the reconnect sequence
  resets the in-RAM mode before the display settles

DIP switch Win-side override (keymap.c):
- Replace rgb_matrix_mode() / rgb_matrix_sethsv() calls (which write to
  EEPROM and permanently overwrite the Launcher mode) with a
  dip_win_active flag; rgb_matrix_indicators_advanced_user() paints all
  LEDs white each frame when the flag is set, leaving the active effect
  and EEPROM untouched

VIA keymap address pinning (config.h):
- Define VIA_EEPROM_MAGIC_ADDR 544 to anchor VIA keymap storage at a
  fixed EEPROM offset; without this, growth in EECONFIG_KB_DATA_SIZE
  silently shifts the keymap block, corrupting stored layouts (observed
  as layer-0 keys reverting to KC_TRNS / KC_NONE on boot)

keyboards/keychron/q5_max/ansi_encoder/config.h

@@ -45,6 +45,14 @@
 
 #endif
 
+// Pin VIA keymap storage to a fixed EEPROM address.  By default VIA places its
+// magic/keymap block immediately after EECONFIG_KB_DATA_SIZE, so any growth in
+// the Keychron custom-RGB EEPROM region shifts the keymap silently and corrupts
+// the stored layout (observed as layer 0 keys reverting to KC_TRNS on boot).
+// 544 is past the current Keychron data region and leaves headroom for further
+// EEPROM additions without requiring another VIA reset.
+#define VIA_EEPROM_MAGIC_ADDR 544
+
 /* Number of layers */
 #define DYNAMIC_KEYMAP_LAYER_COUNT 6