[Bug] Pi sessions are missing from Skill and Memory Bridge L1 prefix fallback

OpenClaw Version | OpenClaw 版本

N/A — Pi 0.84.1

Plugin Version | 插件版本

feat/server_team @ 0b7bc09; MemoryProxy

Operating System | 操作系统

Windows 11 (source-level, OS-independent)

System Specification | 系统配置

N/A

Describe the bug | 问题描述

The Skill Bridge and Memory Bridge L1 session resolvers do not include the pi: agent prefix.

The main OpenAI-compatible handler stores Pi sessions in SessionStore under the composite key pi:<sessionId>. However, both bridge implementations only probe the bare session ID, codebuddy:<sessionId>, and claude-code:<sessionId>.

Therefore, an initialized Pi session already present in the same process is always missed by the bridge L1 fast path. Under normal conditions this is masked by the persistent L2 binding fallback. If the binding repository is unavailable, returns no binding, or encounters a transient read failure, both bridges reject the request with HTTP 401 even though the initialized Pi session is still available in L1 memory.

Affected locations:

• MemoryProxy/src/skill/skill-bridge.ts (loadSessionIdsL1)
• MemoryProxy/src/memory/memory-bridge.ts (loadSessionIdsL1)

To Reproduce | 复现步骤

1. Start MemoryProxy with the first-class Pi adapter and session initialization enabled.
2. Complete Pi session registration for a session such as session-123.
3. Confirm that SessionStore contains the initialized session under pi:session-123.
4. Call either the Skill Bridge or Memory Bridge with x-conversation-id: session-123.
5. Make the L2 binding unavailable or have getBinding() return null, while leaving the same-process L1 session intact.
6. Observe that loadSessionIdsL1() probes only the bare, codebuddy:, and claude-code: keys. It does not probe pi:session-123.
7. The bridge returns HTTP 401 session not initialized despite the valid Pi session being present in L1.

Expected behavior | 预期行为

Both bridges should resolve an initialized Pi session from the L1 key pi:<sessionId> without requiring the L2 binding fallback.

The implementation should also avoid introducing another independently maintained agent-prefix list if possible. Candidate prefixes should be shared with or derived from the registered AgentKind values, with regression coverage for both the Skill Bridge and Memory Bridge.

Error Logs / Screenshots | 报错日志/截图

Typical behavior when L1 misses and L2 cannot recover the binding:

[skill-bridge] session=session-123 L1 miss → L2 binding lookup
HTTP 401
{"code":40101,"message":"[skill-bridge] session not initialized; cannot derive identity"}

The Memory Bridge has the equivalent failure:

{"code":40101,"message":"[memory-bridge] session not initialized; cannot derive identity"}

Additional context | 补充信息

This was found while validating the first-class Pi integration from #1126.

It is related in pattern to #1246: both problems are caused by hardcoded agent name lists drifting from the AgentKind registry. However, #1246 concerns URL whitelist normalization, while this issue concerns the Skill and Memory Bridge L1 session lookup.

The healthy L2 binding path currently masks the problem, which is why normal Pi skill-sync and memory-search flows can still succeed. The bug becomes visible when L2 recovery is unavailable even though the same-process L1 session remains valid.