Refactor RAG from agent-level config to standard toolset type

[dgageot]

Replace the special-cased RAG configuration (AgentConfig.RAG []string referencing top-level Config.RAG map) with a standard toolset type (type: rag) that follows the same patterns as MCP and other toolsets.

Key changes:

• Add 'type: rag' to toolset registry with ref support for shared definitions
• Introduce RAGToolset wrapper (mirrors MCPToolset) for top-level rag section
• Add RAGConfig field to Toolset for inline/resolved RAG configuration
• Add resolveRAGDefinitions() mirroring resolveMCPDefinitions()
• Extract rag.NewManager() for per-toolset manager creation
• Implement tools.Startable on RAGTool for lazy init and file watching
• Remove RAG special-casing from Team, LocalRuntime, and teamloader
• Add v6→v7 migration for old rag agent field to toolset entries
• Update schema, docs, and all example YAML files

Assisted-By: docker-agent

[docker-agent]

Assessment: 🟡 NEEDS ATTENTION

Found 3 issues requiring attention: 1 high-severity potential nil pointer dereference and 2 medium-severity logic issues in the RAG toolset refactoring.

[docker-agent]

🔴 HIGH SEVERITY: Nil pointer dereference

The handleQueryRAG method calls t.manager.Query(ctx, args.Query) without checking if t.manager is nil. While the normal construction path via createRAGTool ensures the manager is non-nil, the Start() and Stop() methods both include defensive nil checks (if t.manager == nil { return nil }), suggesting that a nil manager is considered a valid state.

If a RAGTool is somehow constructed with a nil manager (e.g., through a test fixture or future code path), invoking the query_rag tool will panic.

Recommendation: Add a nil check at the start of handleQueryRAG:

func (t *RAGTool) handleQueryRAG(ctx context.Context, args queryRAGArgs) (*tools.ToolCallResult, error) {
    if t.manager == nil {
        return nil, fmt.Errorf("RAG manager not initialized")
    }
    // ... rest of implementation
}

[docker-agent]

⚠️ MEDIUM SEVERITY: RAG events may be misattributed after agent handoff

The ragEventForwarder closure captures the runtime and reads r.CurrentAgentName() at the time each event is processed (line 14), not when the RAG tool is initialized. If an agent starts a long-running RAG indexing operation and then hands off to another agent, subsequent indexing events will be attributed to the new agent rather than the agent that initiated the operation.

This could confuse users in the TUI, as RAG indexing progress would appear under the wrong agent's context.

Recommendation: Capture the agent name at the time the forwarder is created:

func (r *LocalRuntime) ragEventForwarder(sendEvent func(event.Event)) func(rag.Event) {
    agentName := r.CurrentAgentName()  // Capture once at creation time
    return func(e rag.Event) {
        sendEvent(event.Event{
            Type:      event.TypeRAG,
            AgentName: agentName,  // Use captured name
            RAG:       &e,
        })
    }
}

[docker-agent]

⚠️ MEDIUM SEVERITY: RAG initialization timing unclear

The old code in pkg/app/app.go (removed lines 119-131) called StartBackgroundRAGInit() early in the application lifecycle to begin indexing before the agent loop started. The new design relies on the tools.Startable interface and RAGTool.Start() method, but the diff doesn't show where Start() is called.

If Start() is only invoked lazily (e.g., when the tool is first used), RAG indexing will be delayed compared to the previous behavior, potentially degrading user experience.

Recommendation: Verify that Start() is called early in the toolset initialization path (e.g., in configureToolsetHandlers or during agent setup) to maintain the previous early-indexing behavior. If not already implemented, add an explicit call to start RAG tools during agent initialization.

[rumpl]

I <3 when we remove things from the runtime