Fix ZooKeeper cluster e2e and correct the supported server version to 3.6+

The Cluster ZK e2e tests failed (oap1 unhealthy): the OAP's new Curator 5.9.0 /
ZooKeeper 3.9.5 client cannot register its instance against the e2e's EOL
zookeeper:3.5 server. Reproduced locally: Curator 5.x ServiceDiscovery
(watchInstances=true) issues `addWatch` (persistent watch, opcode 106), which
ZooKeeper added in server 3.6.0; a 3.5 server rejects it ("Received packet at
server of unknown type 106") so the create request fails with ConnectionLoss ->
ModuleStartException -> oap1 unhealthy. Verified the same path succeeds on
zookeeper:3.6 and 3.9, fails on 3.5.

- e2e: bump zookeeper:3.5 -> zookeeper:3.9 (matches the bundled 3.9.x client) in
  cases/cluster/zk/{es,banyandb}.
- Correct the documented minimum from 3.5+ to 3.6+ (application.yml,
  backend-cluster.md, changes.md) -- persistent watches require server 3.6.0.

Author: wu-sheng

docs/en/changes/changes.md

@@ -301,7 +301,7 @@
 * Add `@Stream(allowBootReshape = true)` opt-in for additive boot-time reshape of BanyanDB streams / measures. Code-defined stream classes (e.g. `AlarmRecord`) can now annotate their schema as eligible for in-place additive update at OAP boot — a new `@Column` is appended to the live tag-family / fields via `client.update` instead of being silently rejected with `SKIPPED_SHAPE_MISMATCH` (which previously forced operators to drop the measure / stream and lose historical rows). Additive includes both new tags / fields **and** relocating an existing tag between families when a `@Column`'s `storageOnly` flag flips (e.g. `id1` moving from `storage-only` → `searchable` when it becomes indexed). The opt-in is per-stream and gated by an `isPurelyAdditive` shape diff: tag type changes, tag drops, kind flips (tag↔field), entity / interval / sharding-key changes, and field re-typing still skip with `SKIPPED_SHAPE_MISMATCH`, so identity-breaking edits remain explicit operator actions. Only the init / standalone OAP performs the reshape; non-init peers continue through the existing poll-and-wait loop so a single node drives DDL. When a `check*` records `SKIPPED_SHAPE_MISMATCH` the dependent `IndexRule` / `IndexRuleBinding` reconciliation is also skipped — preventing the previous gap where the binding silently updated to a tag list that diverged from the live tag-family layout. `AlarmRecord` is opted in. Default remains `false` for all other models — boot-time reshape stays off unless the annotation is explicitly set. **Operator caveat:** BanyanDB does not physically migrate existing rows when a tag's family changes; pre-existing data stays in its original on-disk location while new writes go to the declared family — expect a backfill window for queries that route through new IndexRules on relocated tags.
 * Mask keywords `trustStorePass`, `keyStorePass` by default.
 * Bump up dependencies to clear CVE alerts on shipped OAP jars: log4j `2.25.3` → `2.25.4`, jackson `2.18.5` → `2.18.6`, kafka-clients `3.4.0` → `3.9.2`, postgresql `42.4.4` → `42.7.11`, commons-compress `1.21` → `1.26.2`.
-* Bump Apache Curator `4.3.0` → `5.9.0` and Apache ZooKeeper `3.5.7` → `3.9.5` together to clear CVE-2023-44981 (the bundled ZooKeeper jar carried it; OAP is a ZooKeeper client only, so the server-side bug was never reachable, but the jar tripped Dependabot). The cluster-zookeeper and configuration-zookeeper plugins use only stable Curator APIs, so no source changes were required. Operator-facing change: the supported ZooKeeper server version is now 3.5+ — ZooKeeper 3.4.x is no longer supported.
+* Bump Apache Curator `4.3.0` → `5.9.0` and Apache ZooKeeper `3.5.7` → `3.9.5` together to clear CVE-2023-44981 (the bundled ZooKeeper jar carried it; OAP is a ZooKeeper client only, so the server-side bug was never reachable, but the jar tripped Dependabot). The cluster-zookeeper and configuration-zookeeper plugins use only stable Curator APIs, so no source changes were required. Operator-facing change: the supported ZooKeeper server version is now 3.6+ (Curator 5.x uses ZooKeeper persistent watches, added in server 3.6.0); older servers (3.5.x, 3.4.x) are no longer supported.
 * Bump test-scope assertj-core `3.20.2` → `3.27.7` to clear CVE-2026-24400 (XXE in `isXmlEqualTo`, not used by any test).
 * Fix: continuous profiling policy validation now rejects a threshold / count of `0` to match the error messages and rover's `value >= threshold` trigger semantics (a `0` threshold would always trigger). CPU percent and HTTP error rate are tightened from `[0-100]` to `(0-100]`.
 * Fix wrong BanyanDB resource options in record data.

docs/en/setup/backend/backend-cluster.md

@@ -82,7 +82,7 @@ You could have two options
 Zookeeper is a very common and widely used cluster coordinator. Set the **cluster/selector** to **zookeeper** in the yml
 to enable it.
 
-Supported Zookeeper server version: 3.5+. The bundled ZooKeeper client library is 3.9.x.
+Supported Zookeeper server version: 3.6+. The bundled ZooKeeper client library is 3.9.x.
 
 ```yaml
 cluster:

oap-server/server-starter/src/main/resources/application.yml

@@ -16,7 +16,7 @@
 cluster:
   selector: ${SW_CLUSTER:standalone}
   standalone:
-  # Supported ZooKeeper server version: 3.5+. The bundled ZooKeeper client library is 3.9.x.
+  # Supported ZooKeeper server version: 3.6+. The bundled ZooKeeper client library is 3.9.x.
   zookeeper:
     namespace: ${SW_NAMESPACE:""}
     hostPort: ${SW_CLUSTER_ZK_HOST_PORT:localhost:2181}

test/e2e-v2/cases/cluster/zk/banyandb/docker-compose.yml

@@ -15,7 +15,7 @@
 
 services:
   zk:
-    image: zookeeper:3.5
+    image: zookeeper:3.9
     expose:
       - 2181
     networks:

test/e2e-v2/cases/cluster/zk/es/docker-compose.yml

@@ -15,7 +15,7 @@
 
 services:
   zk:
-    image: zookeeper:3.5
+    image: zookeeper:3.9
     expose:
       - 2181
     networks: