feat(agent): per-agent skill allowlist + Skill selection UI

[sloppamadewithlove]

Summary

Adds a per-agent skill allowlist so each agent starts with zero skills and only explicitly enabled skills are exposed via the built-in load_skill tool. This is the backend + desktop UI for per-agent skill selection.

Motivation

Today every Buzz agent auto-loads every skill found on disk. This adds a "Skill selection" panel at the very bottom of each agent's runtime tab so a user can toggle exactly which skills an agent has access to, starting all-off.

Changes

• crates/buzz-agent — new skills_allowlist on Config, parsed from BUZZ_AGENT_SKILLS env (comma/space-separated skill names). Default is empty = zero skills. Discovery + load_skill gated by the allowlist.
• Desktop (Tauri) — new list_installed_skills command enumerating all skills across the runtime skill dirs (.agents/, .codex/, .claude/, .goose/, .buzz/.agents/), deduped + sorted by frontmatter name/description.
• React — new SkillSelectionPanel: fixed-height scrollable box at the bottom of the agent runtime tab, one on/off Switch per skill, all-off default. Writes the enabled set to BUZZ_AGENT_SKILLS, riding the existing spawn-env path.

Notes / review asks

• The desktop half (Tauri command, React panel) is written against existing app patterns but could not be compiled locally (local Tauri build requires a prebundled buzz-acp binary that only exists in the project's build/CI environment). This PR relies on CI to typecheck the desktop changes.
• Behavior change by design: existing agents now start with zero skills instead of auto-loading everything.
• Toggles control Buzz's own discovery/load_skill only; they do not rewrite each runtime's config.toml.

[wolfyy970]

I like the user-facing direction here: an agent should only get the Skills selected for it.

I have restacked #4600 as the shared content and identity layer underneath this. It provides one Agent Skills parser, exact directory content, and a stable digest, so this PR can stop maintaining a second parser without making a local path or same-named folder the portable identity.

Two boundaries look important:

• existing agents need a migration path before empty changes from all Skills to none, or an upgrade silently removes capabilities;
• BUZZ_AGENT_SKILLS should be generated launch input, not the durable definition. The definition should eventually select reviewed Skill content by digest and show Setup required when a target does not have it.

If that split makes sense, I can help wire this branch to the shared parser while you keep the selection UI and runtime gating here.

[wolfyy970]

I like the direction, but I don’t think this is safe to merge as an agent-wide control yet.

The switch currently changes Buzz Agent only. Codex, Claude, Goose, Pi and Hermes still discover Skills through their own runtimes, so Desktop can show zero enabled while those agents can use everything on disk. The list also comes from Desktop’s home, not the agent’s workspace or execution target, which makes it wrong for project Skills and remote agents.

Name-only selection is the other hard boundary. Desktop and Buzz Agent scan different roots in different orders, so a project Skill can silently replace the same-named global Skill the owner reviewed. Existing agents also have no migration: an unset env value changes from all Skills to none, while unset and explicit none cannot be distinguished.

I think this should build on #4600. Persist reviewed Skill references and digests in the agent definition, resolve them on the execution target, then generate runtime-specific launch input. The UI can show missing Skills, restart required, and whether the running generation applied the selection. I would land Buzz Agent enforcement first behind that migrated typed field, then add each runtime when it has a real enforcement path.

I checked the current head locally. TypeScript compiles; Rust formatting currently fails, but that is mechanical rather than the product blocker.