Define a write contract for configured skills #2184

Relates to #1853, #1779.

Problem

Studio shows Edit, Disable, and Delete for a configured skill, permanently disabled, because the daemon offers nothing behind them. The client API has ListSkills (name, description, owner, version) and no way to create, edit, disable, delete, or upload a configured skill. #1779 holds these controls read-only "until a separate approved write contract exists"; this issue is that contract.

It is a design question as much as a missing method. In mecak8s, skills are directories the operator mounts (a ConfigMap, a PVC, or an OCI artifact under <XDG_CONFIG_HOME>/mecatl/skills), and the daemon never writes them. Skills are also resolved once when the server is built, so a change does not reach a running process. A write path has to decide where skills live and who may change them before any RPC makes sense.

Outcome

An approved, documented contract for managing configured skills in a deployment, or an explicit decision that it should stay out of band.

Scope

Decide, and record in an ADR:

• where an editable skill is stored, and how that coexists with operator-mounted, read-only skills in mecak8s and with --skills-dir in mecated;
• who is authorized to create, edit, disable, and delete, and how that is audited;
• what "disable" means, and whether and how a running process picks up a change;
• conflict handling, in the style of the learned-skill expected_revision check;
• the RPC surface, bounds, and capability flag.

Implementation follows as separate issues once the contract is approved.

Acceptance

• An ADR is accepted, or a decision to keep management out of band is recorded.
• Follow-up implementation issues exist for each layer and are linked here.

Delivery

Decision first. No code until the contract is approved.

Fully or partially written by an AI agent.