Feature: per-target agent frontmatter transformation during deployment

[Mathf18]

Problem

When APM deploys agent .md files from a marketplace plugin to multiple targets (Claude Code, OpenCode, Codex, etc.), it copies the same file verbatim to each target directory (.claude/agents/, .opencode/agents/, .codex/agents/).

This causes errors when agent frontmatter fields use platform-specific formats:

tools field

• Claude Code expects: comma-separated string or array → tools: Read, Grep, Glob or tools: ["Read", "Grep"]
• OpenCode expects: record/object → tools: {write: false, bash: false}
• Result: OpenCode rejects the Claude format with "expected record, received array"

color field

• Claude Code expects: named colors → color: cyan
• OpenCode expects: hex or theme names → color: "#00FFFF" or color: warning
• Result: OpenCode rejects named colors with "Invalid hex color format"

Current workaround

Remove both fields entirely so agents work on all platforms (agents inherit all tools and use default colors). This loses tool restrictions and visual identity.

Related PR: https://github.com/data-goblin/power-bi-agentic-development/pull/new/fix/remove-opencode-incompatible-frontmatter

Proposed solution

During apm install --target <platform>, APM should transform agent frontmatter fields to the target platform's expected format:

1. tools: Convert between array (Claude) and record (OpenCode) formats
2. color: Convert between named colors (Claude) and hex/theme colors (OpenCode)
3. Unknown fields: Strip fields not supported by the target platform (e.g., Codex uses TOML, not markdown frontmatter)

This would allow plugin authors to write agent files once in any supported format, and APM would handle the translation during deployment.

Environment

• APM version: 0.8.10
• Plugin: data-goblin/power-bi-agentic-development v0.17.2
• Targets affected: OpenCode (confirmed), potentially Codex and Cursor

[Mathf18]

Related: #293 (Support tool overrides for installed agent packages) — that issue covers consumer-side tool overrides in apm.yml. This issue is about APM itself translating agent frontmatter fields between incompatible platform schemas during apm install --target <platform>, so plugin authors don't need to worry about per-platform format differences.