Discover skills and agents already installed by other agent tools on the machine

## Before filing
- [x] Searched duplicates · [x] Recent release · [x] One request

## Closest existing issue
`none found`

## Kind
`New capability — Berd can't do this at all today`

## The problem, in your terms

I already run a set of agent tooling on this machine, installed for Claude Code
and organised as plugins under `~/.claude/plugins/` — things like a
response-style plugin and a diagram-building plugin, each bundling its own
skills and subagents. They took real work to write and tune.

Berd doesn't see any of it. Berd reads skills from its own locations
(`~/.agents/skills`, `~/.local/share/xyz.block.berd/skills`) and agents from
`~/.agents/agents`, so everything I've built for the other tool is invisible
here. To use any of it in Berd I'd have to copy each one across by hand and then
keep both copies in step forever.

The result is that the capability I care about is split across two homes, and
Berd starts empty even though the machine it's running on is full of exactly the
kind of thing Berd is designed to use.

## What you do today

Nothing, for the ones I haven't got round to. For the few I wanted in both
places I copied the folders manually, which means they now drift — a fix in one
copy doesn't reach the other.

## What you'd like to see

Let Berd discover skills and agents that already exist on the machine in other
tools' directories, rather than only its own.

Rough shape, in the order I'd value it:

1. **Read-only discovery.** Berd finds them, lists them, and marks where each one
came from. No copying, no writing into the other tool's directory.
2. **Explicit opt-in.** A setting listing the directories Berd will scan, empty
by default. Nothing gets picked up without me adding the path.
3. **An import action** for anyone who does want their own editable copy — Berd
already imports agents from zip files, so this is close to something that
exists.

I'd take (1) and (2) alone and be happy.

## Why this belongs in Berd itself

Skill and agent discovery is the app deciding what to load at startup and from
where. A skill can't change that, and neither can an agent, an extension or an
automation — they're the things being discovered. There's no configuration hook
for it either: the paths are fixed in the app.

The formats are close enough that this looks more like a path problem than a
translation problem. Both sides use a folder with a `SKILL.md`, and both use
Markdown-with-frontmatter for agents. Berd's own `skill-builder` and
`agent-builder` describe the same shapes.

## Non-goals

- **Not asking Berd to support another tool's full plugin runtime** — hooks,
slash-command wiring, or anything that only makes sense inside that tool. Just
the skills and agents.
- **Not asking for automatic scanning of my home directory.** Opt-in paths only.
Silently loading whatever it finds would be wrong, and a security problem.
- **Not asking Berd to write into another tool's directories.** Read-only, in
that direction.
- **Not asking for two-way sync.** One direction is enough; sync is a much bigger
promise and I'm not asking for it.

## Alternatives you considered

- **Symlinking `~/.claude/plugins/*/skills` into `~/.agents/skills`.** Might
work, but it's undocumented, fragile across updates on both sides, and not
something most people would find.
- **Copying everything in manually.** What I do now for a few. It drifts, which
is the actual cost.
- **Maintaining one canonical directory and symlinking both tools at it.**
Requires the other tool to cooperate too, and it isn't Berd's to change.

## Context

Environment: Berd 0.6.2, Linux (Ubuntu, x86_64), `.deb` release.

Start by tracing Berd's startup discovery for ~/.agents/skills and ~/.agents/agents, then review the skill-builder and agent-builder descriptions of the supported formats. Done means configured directories are scanned read-only, discovered items show their source paths, and no paths are scanned by default.

Written by the indexing model from the issue text.