Plugin API: let a self-contained feature live outside core

## Problem

A self-contained feature cannot be self-contained. To exist it edits the closed handler record, a channel
and its publisher, the web transport, the store, a panel switch, and several closed unions.

I maintain a fork where seven features have that shape: Claude Code integration, Blueprint, Discord
presence, PDF preview, visualize beside a terminal, a branch graph, and, provisionally, file-type icons.
Each landed as a cross-cutting edit through core, which makes them expensive to keep rebased. The rest of
the fork belongs in core rather than in plugins, and is filed as separate issues.

The spec dialect viewer in core has the same shape from the inside.

## Proposed solution

A plugin contract:

- Manifest plus a host half, a web half, or both.
- Namespaced wire methods and channels, one HTTP route.
- PTY environment, git through the host's runner, agent tools, pi extensions, skills.
- Settings namespace, persisted state, bounded UI contributions.
- Builtin and external plugins get identical capabilities.
- Hot enable and disable: no restart, no reload.
- One API generation integer plus a committed API report.
- Params validated at dispatch against the plugin's schema.
- A UI kit, so out-of-bundle UI looks native.

The first plugin would be the spec dialect: yours, builtin, and a real feature to exercise the contract.

## Alternatives considered

- More per-feature seams: the status quo.
- pi extensions alone: no wire, routes, settings, UI.
- Restart on toggle, as VS Code does: rejected.
- A plugin service registry: the wire surface suffices.

## Additional context

Two drafts against current `main`, following the repo's spec conventions:

- [`packages/plugin-api/SPEC.md`](https://github.com/CommanderTvis/thinkrail/blob/plugin-api-skeleton/packages/plugin-api/SPEC.md) — the contract.
- [`plugin-adoption.md`](https://github.com/CommanderTvis/thinkrail/blob/plugin-api-skeleton/plugin-adoption.md) — the seams and how the features map onto them.

Asking whether upstream wants this direction, and whether the shape looks right.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Start by reading packages/plugin-api/SPEC.md and plugin-adoption.md, including the two linked drafts and the seams they describe. This issue is seeking agreement on a broad plugin contract rather than naming an implementation entry point; done would require an accepted direction and scope for the proposed API.

Written by the indexing model from the issue text.