Bug report: patch_stock_configs() hardcodes F008 motor_control.cfg, corrupts K2 Pro units

[k0ldfuzi0n]

Hi — first off, thanks for maintaining this fork. I've been running it on a K2 Pro (not the K2 Plus this fork targets), and hit a bug in scripts/system.sh that's worth flagging, since it silently breaks the printer on every boot rather than failing loudly.

In patch_stock_configs():

local motor_cfg="$CONFIG_DIR/motor_control.cfg"
local stock_motor_cfg="/rom/usr/share/klipper/config/F008_CR0CN240319C13/motor_control.cfg"
if [ -f "$motor_cfg" ] && [ -f "$stock_motor_cfg" ]; then
    if ! diff -q "$stock_motor_cfg" "$motor_cfg" > /dev/null 2>&1; then
        cp "$motor_cfg" "${motor_cfg}.before_patch" 2>/dev/null
        cp "$stock_motor_cfg" "$motor_cfg"
        log_success "Restored motor_control.cfg from stock (was truncated/modified - this caused X-axis tracking errors during CFS cuts)"
    fi
fi

This function is called unconditionally from /etc/rc.local on every boot (patch_stock_configs), which itself runs on every single boot. The stock_motor_cfg path is hardcoded to the F008 (K2 Plus) board template. On a K2 Pro (F012, single Z motor), the live motor_control.cfg will always differ, it's a different board with a different motor topology.

Klipper crashes on connect with RuntimeError: No active exception to reraise inside motor_control_wrapper.set_motor_pin, and CFS flashes red/hangs indefinitely on SET_BOX_MODE. Both traced back to the wrong (F008) motor profile being active. Any manual fix to motor_control.cfg got silently reverted on the next reboot, which made it look like file corruption or a race condition until I found this function.

Creality's own /etc/init.d/klipper already does correct per-board detection for exactly this purpose, using get_sn_mac.sh model / get_sn_mac.sh board:

case $model in
    "F008") config_dir=F008_CR0CN240319C13 ;;
    "F012"|"F021"|"F025"|"GS-04"|"Z2") config_dir=F012_CR0CN200400C10 ;;
    ...
esac

patch_stock_configs() could reuse the same detection instead of a hardcoded path, e.g.:

local model=$(get_sn_mac.sh model)
local stock_board_dir=
case "$model" in
    F008) stock_board_dir="F008_CR0CN240319C13" ;;
    F012|F021|F025|GS-04|Z2) stock_board_dir="F012_CR0CN200400C10" ;;
esac
local stock_motor_cfg="/rom/usr/share/klipper/config/${stock_board_dir}/motor_control.cfg"

That keeps the safety net you added (which I assumes fixes something on K2 Plus units) while making it board-aware instead of assuming every unit running this fork is a K2 Plus. I may be overlooking some other differences between the units (my mind goes to the z-tilt stuff), but I think they're close enough that it should be pretty workable.

Happy to test a patch on my unit if useful. Everything else about the fork has worked great on my K2 Pro once this was sorted.