refactor(rag): make the rag toolset opt-in to drop cgo from embedders

[dgageot]

The rag toolset depends on go-tree-sitter, which is cgo-only and has no pure-Go fallback. Two static import edges dragged it into the binary of every embedder of this library: pkg/teamloader's registry hard-coded the rag creator, and pkg/runtime type-asserted the concrete *builtinrag.ToolSet to wire indexing-progress events into the UI. Because pkg/runtime, pkg/embeddedchat, and pkg/teamloader are exactly what downstream embedders import, they all linked tree-sitter even when rag is never configured. That forces those embedders to build with CGO_ENABLED=0 (or ship a C toolchain) when cross-compiling to targets like Windows, purely to satisfy a dependency they don't use.

This change makes rag opt-in without changing the CLI's behavior. teamloader now exposes RegisterToolsetCreator, and the rag package self-registers its rag creator from an init(), so a single blank import is enough to enable it. The runtime no longer references the concrete rag type; it asserts a small EventForwarder interface defined in the pure-Go pkg/rag/types package instead. cmd/root blank-imports the rag package, so the docker-agent CLI keeps rag exactly as before, while embedders that don't import it get a tree-sitter-free dependency graph and can build with cgo enabled.

The one risk is that an entrypoint which needs rag forgets the blank import, silently turning rag into an unknown toolset type at runtime. A guard test in cmd/root resolves rag against the default registry so that mistake fails the build instead.

[docker-agent]

Assessment: 🟢 APPROVE

This refactor cleanly achieves its stated goal: making the rag toolset opt-in via init() self-registration to eliminate the cgo go-tree-sitter dependency from embedders that don't need RAG.

What was reviewed:

• pkg/teamloader/registry.go — new RegisterToolsetCreator + extraCreators merge pattern
• pkg/tools/builtin/rag/register.go — new init() self-registration
• pkg/rag/types/types.go — new EventForwarder interface and EventCallback type alias
• pkg/runtime/loop.go / pkg/runtime/rag.go — switch from concrete *builtinrag.ToolSet to ragtypes.EventForwarder interface assertion
• cmd/root/toolsets.go — blank import to keep CLI behavior unchanged
• cmd/root/toolsets_test.go — guard test to catch accidental removal of the blank import

Key findings: No bugs found. All hypotheses were verified and dismissed:

• tools.As[ragtypes.EventForwarder] interface assertion — valid; Go generics handle interface type parameters correctly, and *ToolSet satisfies EventForwarder via the type-aliased EventCallback.
• Guard test logic — sound; an empty-config rag call returns errors.New("rag toolset requires either a rag_config block or a ref"), which is non-nil and doesn't contain "unknown toolset type", correctly distinguishing the two cases.
• extraCreators global state / duplicate registration panic — not a concern; init() runs exactly once per binary, no cross-binary shared state, no data race (init completes before any test/main runs).
• Circular import — broken correctly; pkg/teamloader no longer imports pkg/tools/builtin/rag; the dependency now flows in the other direction.

The design pattern (self-registration via init(), panic on duplicate) is idiomatic Go (identical to database/sql drivers) and appropriate here.