feat: explicit skill invocation in TUI and desktop, aligned on a shared runtime contract #1148

Problem

Skill support today is model-driven only: the agent may call the Skill tool when a request looks relevant, but users have no reliable way to explicitly invoke a skill. Three verified gaps:

1. TUI has no manual trigger at all. The prompt fragment advertises the skill catalog and the Skill tool is wired with host gating (packages/cli/src/runtime-bootstrap.ts), but a user who wants a specific skill can only ask for it in prose and hope.
2. Desktop / popup lists only workspace-installed skills. It is fed by skills:list → scanWorkspaceSkills (single-root, {workspaceRoot}/skills/), while the runtime injects from five discovery paths (resolveSkillDiscoveryPaths: {cwd}/.maka/skills, {cwd}/.agents/skills, {workspaceRoot}/skills, ~/.maka/skills, ~/.agents/skills). Agent-visible skills are invisible to users.
3. Desktop skill injection never applies the host-capability gate. Both call sites pass host === undefined (system-prompt-main.ts → buildSkillsPromptFragment, main.ts → buildSkillAgentTool), which the runtime explicitly treats as legacy no-gating. required-tools / required-capabilities metadata is inert on desktop, and the prompt can advertise skills the session cannot load (the desktop tool set is conditionally assembled, so this is not theoretical). The CLI already does this correctly.

Design (agreed)

One shared contract in @maka/runtime (skill-invocation module), consumed by both clients:

• listInvocableSkills(source, host) — five-path scan + host gate + enablement → slim entries; the single source for TUI autocomplete/highlight validation and the desktop discoverable IPC.
• resolveSkillInvocations + composeSkillInvocationMessage — load via the existing loadSkillInstructions semantics (truncation, cleaning, gating) and compose the final user message (instruction blocks carry the existing user-provided trust framing; no permission escalation).

TUI (packages/cli)

• /skill:<name> tokens inline in the input, anywhere in the text, multiple allowed (deduped, order-preserving). /skill: triggers dynamic autocomplete from listInvocableSkills; bare /skill opens a picker (the /model pattern) that only inserts the token.
• Valid tokens are highlighted in the editor in the CLI brand accent color; invalid tokens are simply not highlighted — absence of the affordance is the inactive state (no separate inactive styling).
• Tokens are parsed at submit time; the CLI (not the model) deterministically loads and injects instructions. Failed tokens stay as literal text and the send proceeds with at most a non-blocking notice — sending is the high-frequency path and must never be blocked by skill resolution.

Desktop (apps/desktop + packages/ui)

• The / popup and its inserted text (使用 X 技能：) stay as-is; selecting a skill additionally creates an invocation chip {id, name}.
• Chips render inline at the head of the input flow (flex-wrap container, textarea keeps all native behavior; no contenteditable, no attachment-lane elevation), using the existing Chip primitive (accent) + Blocks icon + name, multiple allowed, hover-to-remove. Chips that are no longer invocable are silently dropped on skills-list refresh — a chip is the active-invocation indicator, so an invalid one must not exist.
• sessions:send gains an optional skillIds field; main resolves and injects via the shared module before runtime.sendMessage. Races resolve silently in favor of sending.
• The discoverable IPC (popup data source) switches to listInvocableSkills, closing gap 2; desktop passes a real HostCapabilities built from the assembled tool list to both injection call sites, closing gap 3.

Delivery plan

Non-goals

• contenteditable rewrite or overlay-highlight tricks in the desktop composer
• forking/patching pi-tui's Editor (highlighting is a render post-process in our subclass)
• registering each skill as a top-level slash command
• any special "inactive" visual state on either client
• desktop skill management (panel stays workspace-scoped)