feat(cli): make arctl init agent scaffold portable harness composition

[ilackarms]

Problem

arctl init agent still treats provider/model selection as source-template configuration, while the current registry and harness model express runtime composition through tagged resource references: Deployment.spec.modelRef, Agent plugin/skill/instruction/MCPServer refs, and compatible harnesses.

The existing ADK template remains useful and must keep working, but newly scaffolded projects should be able to carry the same composition across local development and harness deployments instead of requiring users to rebuild that wiring by hand.

Goal

Bring arctl init agent up to date with the full portable harness composition surface while preserving backward compatibility for today's generated templates.

Proposed scope

• Keep the existing provider/model template choices working.
• Add a model-selection flow aligned with tagged Model resources and Deployment.spec.modelRef.
• Support scaffold-time selection or declaration of:
  • compatible harnesses;
  • Plugins;
  • Skills;
  • Instructions/Prompts;
  • MCPServers.
• Emit canonical refs using kind, namespace, name, and tag with the same defaulting rules as the registry APIs.
• Generate the Agent and Deployment manifests needed to make runtime model ownership explicit.
• Make template hooks/materialization portable across supported harnesses where their contracts allow it.
• Preserve a useful local iteration path and document how local source-template model wiring relates to deployment-time modelRef.
• Add migration/backward-compatibility guidance for existing generated projects.

Product/API questions to settle before implementation

1. Should init select an existing Model, generate a Model manifest, or support both?
2. Should init always generate a Deployment manifest, or offer that as an opt-in?
3. Which composition inputs are selected from the registry versus scaffolded locally?
4. How should a source template represent multiple compatible harnesses without baking in one harness's filesystem/runtime contract?
5. What is the expected local-run behavior when deployment-time Model selection differs from the source-template default?

Acceptance criteria

• Every currently selectable provider template still generates and runs as before.
• Generated Agent manifests contain no deprecated Agent-owned model provider/name fields.
• Generated Deployment manifests use a valid tagged modelRef when a harness requires a model.
• Plugins, Skills, Instructions/Prompts, MCPServers, and compatible harnesses can be represented without hand-editing the generated Agent manifest.
• Generated refs validate and follow namespace/tag defaulting consistently.
• Tests cover existing provider templates, new composition choices, generated manifests, and backward compatibility.
• Documentation clearly distinguishes source-scaffold defaults from deployment/runtime authority.

Relationship

Follow-up to the OSS-M3 Agent model cutover tracked in handoff H-142. The cutover intentionally preserves the current scaffold behavior and leaves this broader UX/template modernization to a separate change.