Allow custom ACP agents to declare provider-native skill roots

[smsunarto]

Problem

customAcpAgents can currently declare how BB launches an ACP agent, its logo, model CLI, and reasoning configuration, but it cannot describe where that agent discovers native skills.

This creates a mismatch between runtime behavior and BB’s composer:

• The ACP agent can discover and use its native skills.
• BB’s / composer menu cannot discover those skills.
• The menu therefore shows only BB-managed built-in, user, project, and plugin skills.

For example, our custom Amp integration uses the official @ampcode/sdk behind an ACP bridge. Amp discovers user skills from ~/.agents/skills, but the provider appears to BB as acp-amp. resolveCommandScanRoots() only has native discovery rules for claude-code and codex, so acp-amp receives an empty provider-native command set.

Proposal

Allow each customAcpAgents registration to declare its native user and project skill roots:

{
  "customAcpAgents": [
    {
      "id": "amp",
      "displayName": "Amp",
      "command": "node",
      "args": ["/path/to/amp-bridge.js"],
      "nativeSkillRoots": {
        "user": [".agents/skills"],
        "project": [".agents/skills"]
      }
    }
  ]
}

Suggested semantics:

• user roots resolve relative to the target execution host’s home directory.
• project roots resolve relative to the selected workspace.

Why configuration rather than an acp-amp special case?

Skill locations are agent-specific. Hard-coding .agents/skills for all ACP providers would make assumptions about unrelated agents, while hard-coding acp-amp would require BB core changes for every new integration.