Dashboard: cannot view/edit skill markdown content

## Problem

The dashboard lists skills but never exposes the underlying `SKILL.md` markdown anywhere in the UI. Users can see a skill exists but cannot read its full content (YAML frontmatter + body) or edit it without dropping to a terminal. This is the single most-needed workflow gap in the dashboard today.

## Priority

**Highest priority in the backlog.** This should be picked up before any other open issue.

## Design bar — "insanely stunning, flat GitHub vibe"

This is not a plain textarea bolted onto a card. The bar is: flat, precise, GitHub-quality typography and code-block styling, with confident, purposeful motion — never gratuitous. Follow the repo's existing design system exactly:

- Use the semantic Tailwind tokens already defined in `frontend/src/index.css` / `frontend/tailwind.config.js` (see `ui-design-tokens` skill if present in the repo, otherwise match the existing app tokens): `bg-surface`, `bg-raised`, `bg-sunken`, `border-line` / `border-line-subtle` / `border-line-strong`, `text-fg` / `text-fg-muted` / `text-fg-subtle`, `bg-accent` / `text-accent`, `shadow-e1/e2/e3`. **Never** hardcode hex values or raw Tailwind grays.
- Flat surfaces, hairline borders, no heavy drop shadows except on the overlay itself (`shadow-e3`).
- Rendered markdown should look like GitHub's own markdown rendering: proper heading scale, fenced code blocks with a monospace font and a subtle `bg-sunken` background, blockquotes with a left accent bar, tables with hairline borders, inline code with a pill-shaped `bg-sunken` background.
- Use `framer-motion` (already installed) for all transitions. Follow the app's existing motion system if a `motion.ts`/tokens file exists (durations ~90–320ms, spring for pop/press, `ease-snap` cubic-bezier for fades). Nothing should snap into existence — nothing should linger either.

## Required interaction flow

1. **Entry point**: Each skill row/card in the skills list gets a clearly visible **"View / Edit"** button (or the whole row is clickable — pick whichever fits the existing list pattern in the repo).
2. **Opening the markdown viewer**: Clicking it opens an overlay/panel (modal or slide-over — match whichever pattern is more idiomatic to the existing dashboard) that:
- Animates in with a cool, purposeful entrance (e.g. scale+fade "pop" from the trigger, or a slide-over from the edge) — not an abrupt `display:block`.
- Shows the skill's full rendered markdown (frontmatter fields shown nicely, e.g. name/description/tags as a small meta header, then the rendered body).
- Has a close affordance (X button, backdrop click, and Escape key) that animates back out symmetrically — it should disappear as smoothly as it appeared, not just vanish.
3. **Edit button inside the viewer**: An **"Edit"** button switches the panel from rendered view to an editable raw-markdown mode:
- Use a proper code/markdown editor experience (e.g. a `` styled like a code editor with a monospace font and line-friendly padding at minimum; a full editor component like CodeMirror/Monaco is a bonus if it fits the existing frontend deps without adding heavy new dependencies — don't over-engineer if a well-styled textarea achieves the bar).
- The transition from rendered → edit mode should be animated (e.g. crossfade or morph), not an instant swap.
4. **Live preview while editing**: While in edit mode, the user can toggle or split-view a **live rendered preview** of their in-progress edits (side-by-side or a "Preview" tab) so they can see exactly what the saved result will look like before committing.
5. **Save button**:
- Validates the edited content before allowing save: valid YAML frontmatter (`name`, `description` required at minimum — match whatever fields the backend's skill schema actually requires), non-empty body.
- Shows inline validation errors (not a generic alert) if invalid — with an animated shake or highlight on the offending section.
- On successful save:
- Persists the new content to the skill's `SKILL.md` file on disk via the backend API.
- **The updated skill must become immediately available to Hermes with no restart required.** This means:
- The backend must write the file such that Hermes's skill loader picks up the change on next read (Hermes skills are read from disk per-invocation / re-scanned, not cached in a way that requires a process restart — confirm this against the actual skill-loading code path used by Hermes, and if any caching layer exists in the dashboard backend itself, invalidate it on save).
- Show a success toast/confirmation animation (checkmark draw-in, brief highlight pulse) confirming the skill is saved and live.
- Closes edit mode back to the (now updated) rendered view, or closes the whole overlay — either is fine as long as the list view reflects the change without a manual page refresh.
- On failure (network error, backend validation rejection), show a clear inline error and do NOT discard the user's edits — keep them in the editor so nothing is lost.

## Acceptance criteria

- [ ] Skill markdown (raw SKILL.md content, including frontmatter) is fetchable via a backend endpoint and rendered in the dashboard.
- [ ] Viewer overlay/panel opens and closes with an animated, non-abrupt transition (enter AND exit).
- [ ] "Edit" button switches to an editable raw-markdown view with a smooth transition.
- [ ] A live preview of the edited markdown is available before saving (split view or toggle).
- [ ] Save validates frontmatter/body and surfaces inline errors on invalid input without losing the user's edits.
- [ ] Successful save persists to the actual `SKILL.md` file on disk and the change is available to Hermes immediately — **no Hermes restart required**. Verify this concretely (e.g. edit a skill, then have Hermes load/view that skill again in the same running session and confirm the new content is returned).
- [ ] All new UI uses the existing design tokens (no hardcoded colors) and existing animation/motion conventions of the app.
- [ ] Closing without saving discards changes cleanly (with a confirm-dialog if there are unsaved edits, to avoid accidental data loss).
- [ ] Works for skills with linked files too, at minimum by showing that linked files exist (full linked-file editing can be a fast-follow, not required for this issue).

## Notes for implementation

- Check how Hermes actually loads skill content (`skill_view` tool / equivalent loader) to confirm there's no cache to invalidate — this is the most important functional requirement in this issue and must be verified, not assumed.
- Reuse or extend the backend's existing skills endpoint(s) rather than introducing a parallel data path.
- Keep the diff scoped to the skills view/editor feature — no unrelated refactors.

Start by examining the existing skills list UI in the frontend to understand the current component structure. Review the backend skills endpoints to see how skill data is fetched and saved. Check the skill loading mechanism in Hermes to confirm the caching behavior and ensure changes are immediately available. The work involves creating a new overlay/panel component with markdown rendering, editing, and live preview, integrating with the existing design tokens and motion system.

索引モデルが issue の本文から書いたものです。