Pin sf_max_bytes as a rejected key

The rename of sf_max_bytes to sf_max_segment_bytes ships no alias, so
the old spelling must reject as an unknown configuration key. Nothing
asserted that. Every existing drift guard -- WsSenderConfigHonoredTest
and QwpConfigKeysTest -- iterates ConfigSchema.all(), so by
construction they can only catch a half-applied rename, never a
whole-registry one: re-introducing the old key would make them pass
just as happily.

testWsConfigString_withSfMaxBytes_fails asserts the ws:: parse fails
with "unknown configuration key: sf_max_bytes", using the existing
assertBadConfig helper and joining the unknown-key rejection cluster
next to the gorilla / init_buf_size / max_schemas_per_connection
tests.

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

Author: mtopolnik

core/src/test/java/io/questdb/client/test/cutlass/qwp/client/LineSenderBuilderWebSocketTest.java

@@ -857,6 +857,15 @@ public void testWsConfigString_withPath_fails() {
                 "unknown configuration key: path");
     }
 
+    @Test
+    public void testWsConfigString_withSfMaxBytes_fails() {
+        // sf_max_bytes is the spelling this key carries in the 1.2.1-1.3.5 jars.
+        // sf_max_segment_bytes replaces it with no alias, so the old spelling
+        // rejects as an unknown key rather than silently configuring nothing.
+        assertBadConfig("ws::addr=localhost:9000;sf_max_bytes=4096;",
+                "unknown configuration key: sf_max_bytes");
+    }
+
     @Test
     public void testWsConfigString_withEgressOnlyKeysSilentlyAccepted() {
         // connect-string.md "Query client keys" and "Multi-host failover": these