feat(cli): emit rules and commands in OpenCode and Kilo flat builds

[waewoo]

Problem

aidd framework build --flat deliberately emits skills, agents, MCP configuration, and selected hook formats, but skips plugin rules/ and commands/ directories for every target.

That was an explicit YAGNI decision because the framework shipped no plugin source in either directory. The contracts therefore mark both artifact kinds unsupported and warn instead of materializing them.

This becomes a real distribution gap once a plugin uses the generators tracked in #788 to create rules or commands: those artifacts are omitted from an OpenCode or Kilo flat archive.

This issue does not assume that PR #745 will be accepted. It is currently a draft, not reviewed or merged. If it is not merged, the Kilo part of this issue should remain blocked or be removed; the OpenCode part remains independently valid.

Scope

• Add flat-build support for canonical plugin-source rules/ and commands/ for OpenCode and, only if Kilo becomes a supported target, Kilo.
• Materialize namespaced rule files under target-owned directories and reference them from:
  • opencode.json[c].instructions for OpenCode;
  • kilo.json[c].instructions for Kilo.
• Materialize namespaced commands under .opencode/commands/ and, conditionally, .kilo/commands/.
• Prefix or namespace emitted filenames by plugin name so two plugins cannot collide.
• Merge instructions safely: retain every user-owned entry, support JSON and JSONC, and make the same build idempotent.
• Apply target-compatible frontmatter conversion and relative-link rewriting.
• Add fixtures containing rules and commands, focused tests, and target golden-build coverage.

Acceptance criteria

• A plugin containing rules/ produces usable OpenCode rules and, once Kilo support is merged, usable Kilo rules.
• Existing user-owned instructions entries survive the build unchanged.
• A plugin containing commands/ produces discoverable commands in .opencode/commands/ and, conditionally, .kilo/commands/.
• Two plugins with identically named rules or commands cannot overwrite one another.
• Re-running an identical build creates neither duplicate files nor duplicate configuration entries.
• Relative links in rules and commands still resolve after flat materialization.
• Outputs without source rules/ or commands/ remain byte-identical to today.
• Unit, integration, golden, typecheck, lint, and target-runtime smoke tests pass for each implemented target.

Prior art in this repository

• The OpenCode flat contract and Kilo flat contract currently declare both artifacts unsupported.
• PluginContentTranslator already owns generic plugin-component translation; its flat command path is relevant prior art.
• buildOpencodeFlatConfig already demonstrates preservation-safe merging of a user-owned flat configuration.
• The ToolBuildContract design deliberately separates per-tool behavior from generic build orchestration.

Historical decision / discussion

The original YAGNI rationale is summarized in this scope comment on draft PR #745, with a permanent link to the historical flat-build design. It was a global decision because no framework plugin shipped these artifacts; it was not a Kilo-specific limitation.

Out of scope

• Other framework targets: Claude, Cursor, Copilot, Codex, and Gemini retain their current rule/command behavior.
• Hook conversion or hook-plugin generation.
• Changes to the pending Kilo PR feat(cli): add Kilo Code support #745 as part of this work.