fix: rebuild stale CAN map on firmware upgrade (new tmpobcmax canary)

The openinverter single-shot MapMessages() guard was using Param::hwaclim
as a "is the map valid" canary. hwaclim has been in every firmware version
for years, so on every upgrade the guard finds it in the saved flash map
and short-circuits — new AddRecv/AddSend entries in chargercan.cpp never
make it into the live canMap.

Symptom on the -S5 bench (verified via openinverter web UI spot values):
tmpobcmax, c1*/c2*/c3* per-module receives, and canenable/idcspnt/udclim
CHAdeMO RX entries were all unmapped despite being in current source.
The Polarity app saw zero charger temperature, zero per-module
current/voltage, and tmpobcmax=0 on 0x211 byte 7.

Fix: switch the canary from hwaclim -> tmpobcmax (added in -S5, never
present in older saved maps) and uncomment canMap->Clear() so the
rebuild starts clean. The early-return guard still kicks in on every
subsequent boot once tmpobcmax is in the map, preserving the original
intent of letting user customizations persist across reboots.

Also bumps VERSTR S5 -> S6 so the openinverter web UI labels this
firmware distinctly from the prior -S5 flash.

#minor

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

include/param_prj.h

@@ -129,7 +129,7 @@
 // SKUDAK customization suffix: bump on every Skudak-side change so the OpenInverter
 // web UI shows a distinct version (e.g. "4=1.20.R-S4") and we can visually confirm
 // the right firmware is flashed. Match the stm32-sine -S<N> convention.
-#define VERSTR STRINGIFY(4=VER-S5)
+#define VERSTR STRINGIFY(4=VER-S6)
 
 /***** enums ******/