Fix javadoc heading levels in GRPCServer and HTTPServer

Downgrade h3→h2 and h4→h3 to comply with javadoc's implicit h1 class heading.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Author: wu-sheng

oap-server/server-library/library-server/src/main/java/org/apache/skywalking/oap/server/library/server/grpc/GRPCServer.java

@@ -44,7 +44,7 @@
  * gRPC server backed by Netty. Used by up to 4 OAP server endpoints (core-grpc,
  * receiver-grpc, ebpf-grpc, als-grpc). gRPC is the primary telemetry ingestion path.
  *
- * <h3>Thread model</h3>
+ * <h2>Thread model</h2>
  * gRPC-netty uses a three-tier thread model:
  * <ol>
  *   <li><b>Boss event loop</b> — 1 thread. Accepts TCP connections, creates Netty channels,
@@ -61,7 +61,7 @@
  *       between messages the thread returns to the pool.</li>
  * </ol>
  *
- * <h3>Application executor</h3>
+ * <h2>Application executor</h2>
  * gRPC's default application executor is an <b>unbounded {@code CachedThreadPool}</b>
  * ({@code Executors.newCachedThreadPool()}, named {@code grpc-default-executor}).
  * gRPC chose this for safety — application code may block (JDBC, file I/O, synchronized),
@@ -81,7 +81,7 @@
  * {@code BatchQueue.produce()} with {@code BLOCKING} strategy which can block the thread
  * — that would freeze the event loop and stall all connections.
  *
- * <h3>Thread policies</h3>
+ * <h2>Thread policies</h2>
  * <pre>
  *                     gRPC default                 SkyWalking
  *   Boss EL:          1, shared                    (unchanged)
@@ -90,7 +90,7 @@
  *                                                   JDK &lt;25: gRPC default (unchanged)
  * </pre>
  *
- * <h4>Worker event loop: {@code cores}, shared by gRPC (default, unchanged)</h4>
+ * <h3>Worker event loop: {@code cores}, shared by gRPC (default, unchanged)</h3>
  * <pre>
  *   cores:    2    4    8   10   24
  *   threads:  2    4    8   10   24
@@ -100,7 +100,7 @@
  * all {@code NettyServerBuilder} instances that use the default. No custom configuration
  * needed.
  *
- * <h3>Comparison with HTTP (Armeria)</h3>
+ * <h2>Comparison with HTTP (Armeria)</h2>
  * <pre>
  *                     gRPC                                HTTP (Armeria)
  *   Event loop:       cores, shared (gRPC default)        min(5, cores), shared
@@ -111,7 +111,7 @@
  * handlers may block on long I/O (storage queries, extension callbacks). On JDK 25+,
  * virtual threads replace both pools.
  *
- * <h3>User-configured thread pool</h3>
+ * <h2>User-configured thread pool</h2>
  * When {@code threadPoolSize > 0} is set via config, it overrides the default with a
  * per-server fixed pool of that size. On JDK 25+ it is ignored — virtual threads
  * are always used.

oap-server/server-library/library-server/src/main/java/org/apache/skywalking/oap/server/library/server/http/HTTPServer.java

@@ -50,7 +50,7 @@
  * Armeria-based HTTP server shared by all OAP HTTP endpoints (core-http, receiver-http,
  * promql-http, logql-http, zipkin-query-http, zipkin-http, firehose-http — up to 7 servers).
  *
- * <h3>Thread model</h3>
+ * <h2>Thread model</h2>
  * Armeria uses a two-tier thread model:
  * <ul>
  *   <li><b>Event loop threads</b> — non-blocking I/O multiplexers (epoll/kqueue). Handle
@@ -66,15 +66,15 @@
  * requests spend most of their time (waiting on I/O), while event loop threads just
  * shuttle bytes and are immediately available for the next connection.
  *
- * <h3>Thread policies</h3>
+ * <h2>Thread policies</h2>
  * <pre>
  *                     Armeria default        SkyWalking
  *   Event loop:       cores * 2 per server   min(5, cores) shared across all servers
  *   Blocking exec:    cached, up to 200      JDK 25+: virtual threads
  *                                             JDK &lt;25: Armeria default (unchanged)
  * </pre>
  *
- * <h4>Event loop: {@code min(5, cores)}, shared</h4>
+ * <h3>Event loop: {@code min(5, cores)}, shared</h3>
  * <pre>
  *   cores:    2    4    8   10   24
  *   threads:  2    4    5    5    5
@@ -83,7 +83,7 @@
  * HTTP servers means 7 * cores * 2 = 140 threads on 10-core — far more than needed for
  * HTTP traffic. All servers share one {@link EventLoopGroup} with min(5, cores) threads.
  *
- * <h4>Blocking executor: Armeria default on JDK &lt;25, virtual threads on JDK 25+</h4>
+ * <h3>Blocking executor: Armeria default on JDK &lt;25, virtual threads on JDK 25+</h3>
  * On JDK &lt;25, Armeria's default cached pool (up to 200 on-demand threads) is kept
  * unchanged. HTTP handlers block on storage/DB queries (BanyanDB, Elasticsearch) which
  * can take 10ms–seconds. A bounded pool would cause request queuing and UI timeouts
@@ -92,7 +92,7 @@
  * On JDK 25+, virtual threads replace this pool entirely — each blocking request
  * gets its own virtual thread backed by ~cores shared carrier threads.
  *
- * <h3>Comparison with gRPC</h3>
+ * <h2>Comparison with gRPC</h2>
  * gRPC is the primary telemetry ingestion path. HTTP is secondary (UI queries, PromQL,
  * LogQL, and optionally telemetry), so it uses fewer event loop threads.
  * <pre>