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>认证逻辑：