feat(channels): support multi-message sending via split marker

[uiYzzi]

📝 Description

Support LLM to proactively send multiple messages via the <|[SPLIT]|> split marker. When SplitOnMarker is enabled in config, the LLM can use this marker in responses to split a single message into multiple independent outbound messages.

Key changes:

• New pkg/channels/marker.go handles split marker logic
• Config field Agents.Defaults.SplitOnMarker controls the toggle, disabled by default
• Frontend config page adds corresponding toggle, labeled "Multi-Message Sending"
• Message chunks exceeding MaxMessageLength will be further split by length

🗣️ Type of Change

• 🐞 Bug fix (non-breaking change which fixes an issue)
• ✨ New feature (non-breaking change which adds functionality)
• 📖 Documentation update
• ⚡ Code refactoring (no functional changes, no api changes)

🤖 AI Code Generation

• 🤖 Fully AI-generated (100% AI, 0% Human)
• 🛠️ Mostly AI-generated (AI draft, Human verified/modified)
• 👨‍💻 Mostly Human-written (Human lead, AI assisted or none)

🔗 Related Issue

📚 Technical Context (Skip for Docs)

• Reference URL:
• Reasoning: Split marker <|[SPLIT]|> is hardcoded in marker.go, not configurable; the toggle is at AgentDefaults.SplitOnMarker level

☑️ Checklist

• My code/docs follow the style of this project.
• I have performed a self-review of my own changes.
• I have updated the documentation accordingly.

[yinwm]

Code Review: Avoid goto in manager.go

The use of goto lengthSplit in the message processing logic is unnecessary and reduces readability. Go community best practices recommend avoiding goto except for specific cases like unified error handling.

Current approach:

• Uses goto to jump to fallback logic when marker is not found or disabled
• Creates non-linear control flow that's harder to follow

Suggested refactoring:
Let the marker splitting try first, then naturally fallback based on result:

var chunks []string

// Step 1: Try marker-based splitting if enabled
if m.config != nil && m.config.Agents.Defaults.SplitOnMarker {
    if markerChunks := SplitByMarker(msg.Content); len(markerChunks) > 1 {
        for _, chunk := range markerChunks {
            chunks = append(chunks, splitByLength(chunk, maxLen)...)
        }
    }
}

// Step 2: Fallback to length-based splitting if no chunks from marker
if len(chunks) == 0 {
    chunks = splitByLength(msg.Content, maxLen)
}

Helper function:

func splitByLength(content string, maxLen int) []string {
    if maxLen > 0 && len([]rune(content)) > maxLen {
        return SplitMessage(content, maxLen)
    }
    return []string{content}
}

Benefits:

• Linear, easy-to-follow control flow
• Less nesting, fewer lines
• splitByLength is independently testable

This is a minor issue but worth addressing for code maintainability.