fix(webconfig): define the in-class constants out of line

LilyGo_TLora_V2_1_1_6 observer builds failed to link:

  undefined reference to `WebConfigServer::MAX_BATCH'
    in handleStatus and handleCliPost

An in-class initialiser is only a declaration under C++11, which is what the
xtensa-esp32 toolchain builds with. Every previous use of MAX_BATCH was a
comparison, which reads the value and needs no symbol. Reporting it as
status.max_cmds, and naming it in the "too many commands" error, passes it to
ArduinoJson — which takes `const T&` — and binding a reference odr-uses it.

It linked on most targets because the compiler folded the reference away, and
failed on the ones where it did not. A cast at the two call sites would have
silenced it just as narrowly; defining the symbols is what stops the next use
from depending on the same luck. MAX_BODY and STOP_WARN_MS get the same
treatment for the same reason, before they are the next to be passed by
reference.

src/helpers/esp32/WebConfigServer.cpp

@@ -133,6 +133,17 @@ struct WCLock {
 WebConfigServer* WebConfigServer::_active = NULL;
 AsyncWebServer* WebConfigServer::_host = NULL;
 
+// Out-of-line definitions for the in-class-initialised constants. An in-class
+// initialiser is only a declaration under C++11 (what the xtensa-esp32
+// toolchain builds with), so any use that binds a reference rather than reading
+// the value — ArduinoJson takes its argument as `const T&` — needs the symbol to
+// exist. Comparisons like `count >= MAX_BATCH` never did, which is why this only
+// surfaced when MAX_BATCH started being reported in JSON, and then only on the
+// targets where the compiler happened not to fold it.
+const int WebConfigServer::MAX_BATCH;
+const size_t WebConfigServer::MAX_BODY;
+const uint32_t WebConfigServer::STOP_WARN_MS;
+
 // Protects the permanent route host's active-session pointer and handler
 // references across the loop and async_tcp cores. The critical sections only
 // copy a pointer/update a counter; handlers themselves never run under it.