Define a versioned analyzer, view, and read-tool extension API

[hellices]

Goal

Define a versioned extension API for deterministic analyzers, read-only tools,
and bounded UI views without weakening korvid's layer or security boundaries.

Current gap

korvid has a versioned provider plugin API and documents korvid.panel and
korvid.tool as architectural directions, but the implemented public plugin
surface is provider-focused. The tool registry explicitly keeps external tool
loading out of scope because collision, exposure, approval, and trust policy
need a dedicated design.

Without a supported extension boundary, integrations either remain in core or
must rely on internal imports that cannot be kept compatible.

Design

Start with three explicitly bounded extension kinds:

1. deterministic analyzers consuming declared resource snapshots and returning
   structured findings;
2. cluster/external read-only tools with typed schemas and result caps;
3. UI views that render extension-owned read models through documented Textual
   interfaces.

Each plugin declares:

• exact korvid API version and normalized unique name;
• extension kinds and entry points;
• required Kubernetes resources/verbs;
• whether results may be exposed to embedded agent, MCP, or UI only;
• network access and configuration keys;
• maximum result/call constraints;
• optional dependencies and supported korvid versions.

Use selected-only loading and collision rejection consistent with the provider
plugin work.

Acceptance criteria

• Public ABCs/types are importable from a documented stable package surface.
• Unknown API versions, duplicate normalized names, invalid schemas, undeclared
  effects, and forbidden exposure combinations fail before runtime use.
• External tools in the first API are structurally read-only; a plugin cannot
  label a write handler as a read tool and reach a mutation bridge.
• Selected-only discovery does not import unselected plugin modules.
• Missing optional dependencies disable only the selected extension with an
  actionable error.
• Plugin-required Kubernetes permissions and model/MCP exposure are visible to
  the user before activation.
• Contract tests include a valid sample plugin and hostile fixtures for
  collision, import side effects, oversized results, schema mutation, and
  attempted write exposure.
• Documentation states that plugins are trusted in-process Python code and are
  not sandboxed.
• At least one external sample analyzer/view demonstrates the API without
  importing korvid internals.

Out of scope

• Third-party cluster-write plugins.
• A plugin marketplace or automatic remote package installation.
• Sandboxing arbitrary Python code.
• Backward compatibility for undocumented internal imports.