webclient: read the skills catalog as documents, split it into two tabs ...

Settings had one long panel mixing skills and protocols as raw markdown,
which was hard to read and wasted the width. Skills and Protocols are now
two tabs over one panel keyed by kind.

Selecting an entry shows the parsed document — triggers, preconditions,
steps, post-checks, escape hatches, body — and an Edit button switches to
the source, so the catalog is read the way the agent loads it. The
single-entry payload carries the parsed document; the list still does not,
so it stays cheap. SkillDocument is shared with the chat proposal card,
which now only draws its own frame and header.

skills: agent-written skills and protocol proposals with chat buttons ...

A skill the agent writes now lands in the catalog on its own; a protocol
never does. `skills(op="propose")` stores the document in `skill_proposals`
and returns a card through the tool result's `ui_component` metadata — no
`render_component` call, so profiles without `navi_ui` get the card too.

The decision is the server's: the browser sends `skill_proposal` over the
WebSocket, `SkillStore.decide_proposal` writes the catalog row from the
*stored* document, names the clicking user as the author, and answers with
`skill_proposal_decided`. The agent learns the outcome as a hidden user
message, the same path a `navi_ui` form submission takes.

`create`/`update` refuse protocol documents and point at `propose` with
`replaces_id`, so the version history of a protocol always starts from a
user's yes. The chat store now renders `ui_component` from any tool whose
result carries one, not only from `mcp__navi_ui__render_component`.

skills: catalog of skills and protocols with a settings tab ...

One registry for reusable methodologies: markdown with YAML front matter,
stored in PostgreSQL alongside a full edit history. A row is either a
`skill` (advice, adapt as needed) or a `protocol` (a committed order of
actions), and a protocol is refused on save unless it declares its steps,
post-checks and the three escape hatches — on_deviation, on_blocked,
on_already_done — because an honest run needs a way out when reality
differs from the plan.

- `SkillStore`: lazy DDL, uniqueness on (owner_id, kind, name), version
  bump with an appended `skill_versions` row, `content_hash` as the only
  hive-sync hook. Personal rows carry an owner; shared rows have an empty
  one and are writable by an admin.
- REST `/skills` (list/get/create/update/delete/versions) and the agent
  tool `skills` (search/load) that renders a compact document — numbered
  steps and escape hatches for a protocol, the instructions for a skill.
- Settings → Скилы и протоколы: catalog with search and kind/area
  filters, a document editor that shows the server's validation error
  verbatim, create from a template, delete, edit history, and the
  personal/shared switch for an admin.

Manuals stay where they are: tool knowledge, separate from this catalog.