docs: align comments with tdengine history path

modules/protocols/protocol-gb32960/src/main/java/com/lingniu/ingest/protocol/gb32960/handler/Gb32960RealtimeHandler.java

@@ -18,7 +18,7 @@ import java.util.List;
  * <p>这是 GB32960 协议在通用 Dispatcher 管线里的**唯一入口** Bean——移除将导致所有
  * GB32960 帧产出的事件丢失。构造器注入 {@link Gb32960EventMapper}，全部业务逻辑限制
  * 在纯函数里，不触碰数据库 / 不做 IO。产出的事件由 Dispatcher 统一投递到 Disruptor；
- * 下游 sink 再决定写 raw archive、DuckDB/Parquet 历史库或转发 Kafka。
+ * 下游 sink 再决定写 raw archive、TDengine 历史库或转发 Kafka。
  *
  * <p>当前 32960 专用 snapshot 查询不依赖 Realtime/Location 事件表，而是通过 raw archive URI
  * 回读原始 .bin 并即时解码合并，避免不同车辆或不同子包之间做大范围 join。

modules/protocols/protocol-gb32960/src/main/java/com/lingniu/ingest/protocol/gb32960/inbound/Gb32960ChannelHandler.java

@@ -29,7 +29,7 @@ import java.util.Map;
  * Netty 入站处理器：字节 → Gb32960Message → 认证 → RawFrame → Dispatcher。
  *
  * <p>这是 32960 生产链路的入口边界。它只做协议层职责：解码、鉴权、应答、组装
- * {@link RawFrame} 并投递 Dispatcher；原始包归档、DuckDB/Parquet 索引、Kafka 转发都在
+ * {@link RawFrame} 并投递 Dispatcher；原始包归档、TDengine 历史索引、Kafka 转发都在
  * 下游 sink 中完成，避免 Netty EventLoop 被存储 IO 阻塞。
  *
  * <p>认证逻辑：

modules/protocols/protocol-jt808/src/main/java/com/lingniu/ingest/protocol/jt808/inbound/Jt808ChannelHandler.java

@@ -111,7 +111,7 @@ public class Jt808ChannelHandler extends SimpleChannelInboundHandler<Object> {
             processDecodedFrame(ctx, frame, msg);
         } catch (RuntimeException e) {
             // 解码成功但业务处理失败时仍派发一条 malformed RawFrame，
-            // 保证原始帧能被 archive/event-file-store 留痕，方便事后排查。
+            // 保证原始帧能被 archive、Kafka 和历史索引留痕，方便事后排查。
             log.warn("[jt808] processing failed peer={} phone={} msgId=0x{} error={}",
                     addr(ctx), msg.header().phone(), Integer.toHexString(msg.header().messageId()), e.getMessage());
             log.debug("[jt808] processing failed stack peer={}", addr(ctx), e);