Multi-session kernel

[JaimeStill]

Context

Part of Objective #2 (Kernel Interface). The kernel must evolve from single-agent/single-session to a multi-session runtime. Sessions are the context boundary for all subsystem integrations (memory, tools, agent selection). This is the foundational refactor that enables the HTTP interface.

Depends on: #23 (Streaming tools), #24 (Agent registry), #25 (Kernel observer)

Scope

Refactor the kernel to manage multiple sessions with agent registry integration.

• Session manager: Create, get, list sessions with lifecycle tracking (active → running → completed/error)
• Session configuration: Agent name (resolved from registry), memory config, parent session ID (foundation for child sessions)
• Per-session memory: Each session gets a scoped memory.Cache. Context injection maps to cache.Save().
• Kernel.Run refactor: Takes session ID + prompt. Resolves agent from session config → registry. Uses streaming (ToolsStream). Emits events via observer.
• Child session foundation: Session model includes ParentID and inheritance config. No subagent spawning or cross-session orchestration — that is deferred to a future objective.
• Kernel.New refactor: Kernel initialized with shared config + agent registry. Sessions created dynamically, not at init.

Approach

• New kernel/session.go with session manager and managed session type wrapping session.Session
• Refactor kernel/kernel.go from single-session struct to multi-session runtime
• Session lifecycle: active (created) → running (Run in progress) → completed/error
• Agent resolved from registry by name when session is created
• Memory Cache per session for context isolation

Acceptance Criteria

• Kernel supports multiple concurrent sessions
• Sessions created dynamically with agent name + config
• Per-session memory via Cache
• Session lifecycle tracking (active, running, completed, error)
• Kernel.Run takes session ID + prompt
• Streaming (ToolsStream) used in loop
• Observer events emitted during loop
• Child session ParentID field in session model (no orchestration)
• Planning notes added identifying future objective for full child session support
• Tests cover multi-session scenarios