Link the Frame skills slot to real registry skills

Motivation

A Frame's skills slot is currently a list of bare strings (backend/internal/frames/schema.go), e.g.:

skills:
  - proposal-writing
  - technical-writing

It names relevant skills but connects to nothing. Meanwhile skillsctl already hosts Claude Code skills as a sibling artifact type on the same registry foundation (see the migration design doc's "Approach A": Frames and Skills share infrastructure but keep separate tables/services). The design doc also flags the typed-list slots as "conservative; richer structures are easy additive evolutions later," and the SkillSource enum (INTERNAL/FEDERATED) already anticipates resolving across registries.

So: let a Frame's skills entries resolve to real skills and render as links.

Proposal

• Schema: allow a skills entry to be a reference (skill name + optional version/source) alongside the existing bare string. Bare strings keep working (back-compatible; unknown-key rejection stays).
• Resolution: when resolving/composing a Frame, resolve each reference against the skill registry (internal skillsctl skills now, FEDERATED sources later) to a title plus an install/detail link.
• Rendering: MCP get_frame output and the web frame view render resolvable skills as links (install command / skill detail page), not plain text.

Scope decision

• Link-only (recommended): Frames references skills; skillsctl stays the host of the skill bundles. Purely additive, respects the deliberate skillsctl/Frames separation.
• Host skill bundles in Frames: Frames stores/serves the multi-file skill packages itself. Much bigger (file storage, multi-file versioning, executable-content security) and re-merges two projects the migration doc split on purpose. Since skillsctl already holds the bundles, linking gets the same "include relevant skills in a Frame" outcome without that weight.

Acceptance criteria

• A Frame can declare skills that resolve to real registry skills.
• Bare-string skills still validate (back-compat).
• MCP get_frame and the web view render resolvable skills as links.
• Unresolvable references degrade gracefully (render the name, note it's unresolved) rather than failing the Frame.

Start with backend/internal/frames/schema.go and trace how Frame skills are validated, resolved, and composed. Then locate the MCP get_frame entry point and the web frame view to understand their current rendering paths. Done means reference entries resolve to skill title and links, bare strings remain valid, and unresolved names render gracefully.