Feat/capability abstraction

[neriousy]

Issue for this PR

Closes #

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Adds a global capability-preference abstraction, initially used only for skills. This keeps mutable user preferences out of Skill.Info and leaves permissions, runtime health, and visibility as separate concerns.

A capability is identified by a typed reference. The only supported kind in this PR is:

{ kind: "skill", key: ["effect"] }

Explicit enabled and disabled preferences are stored through the shared KV service under capability:preferences. inherit removes the explicit preference and restores the skill default, which is derived from autoinvoke.

The capability API returns the default state, explicit preference, and effective state separately. The Skills dialog uses that API, while SkillInstructions applies the effective state when building automatic skill guidance. Explicit @skill references remain available even when automatic discovery is disabled.

To add another capability kind later:

1. Extend Capability.Kind and add a canonical reference constructor such as Capability.tool(name).
2. Add that domain's inventory to the capability API projection.
3. Call capability.resolve(ref, defaultState) at the domain's real availability boundary.
4. Build a domain-specific dialog over the shared preference API.

The preference service only resolves desired activation. Each domain still owns what disabling means.

How did you verify your code works?

• Ran Core, Server, Client, and TUI typechecks.
• Ran capability persistence and skill-instruction tests.
• Ran the existing skill prompt and session tests.
• Regenerated the Effect and Promise clients.

Screenshots / recordings

Not included.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

If you do not follow this template your PR will be automatically rejected.