[警告][性能] [P1] 批量 UB 在确认命中和对象大小前按 key 预留注册内存

证据：基线只允许单 key 进入 inline；这里放开批量后，AllocateUbInlineBuffers 会为每个 item 分别 Allocate(ubBufferSize_)。总量只受默认 32 MiB 的 UB MaxGetSize 限制，因此单请求可预占 32 MiB；并发 32 时约为 1 GiB，而且 100% metadata miss 也会完成全部预分配。

问题：注册内存、allocator/handle、shared ownership 和哈希节点成本与真实命中率及对象大小无关，低命中大 batch 会把元数据查询变成高成本内存路径。

影响：高并发下可能造成注册池压力、allocator/arena 争用、缓存抖动和 UB 到 TCP 的额外回退，抵消 RPC 下沉收益并恶化 P99。

建议：按 owner group 使用连续注册 buffer 并通过 offset 分片，或设置独立的 key 数与字节预算后分块；在有测量依据前至少保留批量 UB 门限。

验证：在配置 DATASYSTEM_UB_GET_DATA_SIZE_BYTES 后，以并发 1/32/128、batch 1/32/1024、命中率 0/50/100% 对比基线，记录 P50/P99、分配次数、注册字节峰值和 TCP fallback 次数。

[警告][安全] [P1] 复用 SHM session 时未刷新当前请求的认证上下文

证据：这里 AcquireSession 复用已有 live session 后直接返回；ShmConnection::Acquire 不更新 ShmSession 或 ShmFdChannel 的 auth。普通 ShmSession::Get 每次请求都会同时刷新二者，而 QueryAndGet 的 BuildQueryAndGetResult 可能触发 GetClientFd，后者使用 ShmFdChannel 中缓存的 token，并与当前 tenantId 组合发请求。

问题：QueryAndGet 主 RPC 可以使用当前凭据成功，但冷 FD 获取仍可能使用 session 创建时或上一次普通 Get 的旧 token/tenant 上下文。

影响：凭据轮换或请求级租户变化后，同机 SHM 命中可能在结果物化阶段稳定失败并使 session 失效；认证上下文错配也触及多租户隔离边界。

建议：提供带锁的 ShmSession::RefreshAuth(context)，在复用 session 后且 dispatch 前原子刷新 session 与 fdChannel 的认证上下文；或让 BuildQueryAndGetResult 显式刷新本次 context。

验证：复用同一 session 后轮换 token/AKSK，并切换 request tenant，构造需要获取新 FD 的 SHM hit，确认 GetClientFd 只使用当前凭据，且失败时有安全降级路径。

[P3] SHM session 在请求构建阶段失效（K_NOT_READY）时整批失败且无 TCP/UB 回退

PrepareShmInlineRequest 成功取得 session 后，若在 AddInlineDataRequest 检查 IsAlive() 时 session 恰好失效（心跳超时窗口），直接返回 K_NOT_READY，QueryWithRetry 立即返回错误，组内所有 key 失败；而 InvokeQueryAndGet 的 lease 失败路径（invoked==false）会走 SwitchInlineRequestToTcp 降级 TCP。同一请求内两条失败路径行为不一致，窗口虽极小但失败模式生硬，建议此处同样降级 TCP 或按 miss 重试。