是否有计划支持「按租户分页查询在线 Session 列表」的 API？

## 背景

我们在基于 BifroMQ 搭建 IoT 接入层，运维同事希望在控制台上有一个"在线设备列表"页面：能按 `tenantId` 分页查看当前在线的 MQTT session（`userId / clientId / 接入 IP / 连接时间 / cleanStart` 等），支持搜索过滤。这是 IoT 运营场景里一个比较高频的需求。

## 我看到的现状

通读了 `bifromq-apiserver` 和 `bifromq-session-dict` 之后，我的理解是：

1. **HTTP 层**：`bifromq-apiserver` 暴露的 session 相关接口都是点操作 —— `GET /session`、`GET /session/inbox`、`DELETE /session`、`POST /kill`，都必须显式传入 `tenant_id + user_id + client_id`，没有 list/page 类接口。
2. **RPC 层**：`SessionDictService.proto` 里只有 `get`（单条点查）和 `exist`（存在性批量校验），同样没有 `list`。
3. **数据存储**：`SessionRegistry.tenantSessions` 是进程内的 `ConcurrentSkipListMap`，按 `(userId, clientId)` 排序、**不落盘**；每个 session-dict-server 节点只持有自己分片的部分。
4. **事件侧**：通过 `IEventCollector` 可以拿到 `CLIENT_CONNECTED / 各种 DISCONNECTED` 事件，业务方可以自己物化一份外部存储。

## 我的猜测（想跟社区确认）

按现有代码推断，"列出在线 session" 这件事**不是疏忽，而是有意没做**：

- **分片架构**：session 按 `tenantId+userId+clientId` 一致性哈希分散在多个 session-dict-server，列表需要扇出 + 跨节点合并/分页。
- **规模假设**：单租户百万连接的体量下，同步返回列表本身就不现实。
- **职责边界**：`apiserver` 定位偏控制面（点操作 + 集群拓扑），不承担"业务查询门户"职责；列表类需求由用户通过 event-collector 自己物化到外部存储更合适。

## 想请教的问题

1. 我对设计意图的理解对吗？社区是否**明确**不打算在 broker 内提供"按租户分页列出在线 session"这类查询，让用户通过 event-collector 自建？
2. 如果不是原则上反对，只是优先级 / 实现复杂度问题，是否可以接受这样一个**轻量级、为运维 / 对账场景设计**的接口？比如：
- 在 `SessionDictService` 增加 `rpc listSessions(...) returns (stream ...)`，server 端复用 `ISessionRegistry.findRegistrations(tenantId)`，基于 `ConcurrentSkipListMap` 的有序性做游标续传（`startKey = userId\u0000clientId`，`limit` 限流）；
- `apiserver` 增加 `GET /sessions`，通过 service discovery 扇出到所有 session-dict-server 实例，按 key 归并；