GeezerVison

Adds ExperimentAgentPlugins, which gates read-only support for Agent
Plugins (agent-plugins.org) found in workspaces. Later commits make the
workspace agent discover plugin manifests and chatd surface their
skills and MCP servers when the experiment is enabled.

…v2.13)

Bumps the Agent API to v2.13 with message-only changes:

- ContextResource gains a PluginBody variant carrying validated Agent
  Plugins (agent-plugins.org) manifest fields, and SkillMetaBody and
  MCPServerBody gain plugin_name for attribution.
- Manifest gains agent_plugins_enabled, set by coderd when the
  agent-plugins experiment is on. Older coderd versions never set it, so
  an agent treats false as both "experiment off" and "peer would reject
  the plugin variant", and keeps dialing v2.10 as v2.11 and v2.12 did.

coderd stores the plugin variant under the existing plugin body kind;
no schema migration is needed.

workspacesdk.ValidatePluginName implements the spec's plugin name
grammar (1 to 64 characters of a-z, 0-9, '.', '-', alphanumeric first
and last, no repeated separators) so the agent and coderd validate
names the same way.

The agentcontext resolver recognizes Agent Plugins (agent-plugins.org,
spec 1.0.0) directories and emits them as KindPlugin resources with
their skills attributed to the plugin.

Discovery: a plugin is an immediate child of plugins/ or
.agents/plugins/ under a scan root, or a scan root that itself holds a
plugin.json. A directory is a plugin only when plugin.json carries an
https://agent-plugins.org/schemas/ $schema; other plugin.json files
are ignored. A scan root that validates as a plugin is emitted as that
plugin only, so its skills/ children are not also emitted as plain
skills. Symlinked plugin directories are skipped. The plugin root is
canonicalized once and is the containment boundary for plugin.json,
mcp.json, the skills/ container, and every SKILL.md; a symlinked or
non-directory skills/ disables the skills component with a warning on
the plugin resource.

Validation follows spec section 5 by hand: name grammar (exported as
ValidatePluginName), optional string fields, keywords as strings,
closed author object, extensions as object. Unknown top-level fields
and a non-object extensions value are recorded in Resource.Error while
the status stays OK; every other violation, an unsupported schema
version, invalid JSON, or an oversize manifest rejects the plugin and
loads no components. Version and description are sanitized and capped
before they reach the resource.

Skills are deduplicated by (PluginName, Name) so a plugin skill and a
plain skill of the same name both survive. A plugin name already
claimed by an earlier scan root makes later same-named plugins
StatusInvalid with no components.

Resource gains PluginName, PluginVersion, and HasMCPConfig;
MCPServerStatus gains PluginName; Snapshot.Plugins() lists the valid
plugins with their roots. The DRPC pusher maps KindPlugin to
PluginBody and sets plugin_name on skill and MCP server bodies, but
only when constructed with WithPluginsEnabled(true); otherwise plugin
resources are dropped and plugin_name stays empty.

Manager.SetPluginsEnabled stores the flag and re-resolves on change;
both resolve paths pass it to Resolver.ResolveWithOptions, and
Resolve/ResolveContext keep plugin discovery off. The agent sets the
flag from Manifest.AgentPluginsEnabled on every manifest and the push
routine waits for the manifest before constructing the pusher with the
same flag.

The fsnotify watcher registers the plugin containers under each scan
root, each immediate plugin directory, its skills/ container, and that
container's immediate subdirectories, and treats plugin.json and
mcp.json events as relevant. Plugin directories are watched regardless
of the flag; the resolver decides what to read.

Adds skills.SourcePlugin and Skill.Plugin for skills shipped inside an
Agent Plugin. MergeSkills takes a third group of plugin skills whose
identity is the (plugin, name) pair, so distinct plugins may each ship
a skill of the same name. A name held by one skill keeps a bare alias;
when several skills share a name every holder gets its qualified alias
(personal/<name>, workspace/<name>, plugin/<plugin>/<name>) in a fixed
order, and Lookup keeps reporting a bare match as ambiguous. The fixed
plugin/ source token keeps plugin names such as "personal" or
"workspace" from colliding with the other sources.

QualifiedAlias becomes a method on Skill so both Lookup and the prompt
index derive the plugin form the same way. Existing callers pass no
plugin skills yet.

…riment

Skills pushed by the workspace agent with a plugin_name now reach the chat
as plugin-source skills. The prompt index lists them as
"- <alias> (plugin: <name>): <description>", collisions qualify them as
plugin/<plugin>/<name>, and read_skill and read_skill_file serve them from
the pinned SKILL.md and the skill directory like workspace skills.
findSkill matches on (source, plugin, name), so two plugins shipping the
same skill name resolve to their own bodies.

The agent-plugins experiment gates every read of plugin-attributed pinned
context. When it is off, plugin manifest rows and skill or mcp_server rows
carrying a plugin_name are dropped from the system prompt, the workspace
MCP tool set, and the chat context resource listing. Hydration and refresh
still pin every row, so flipping the experiment needs no re-pin.

Pinned skill rows are validated before use: skill names must match the
kebab-case skill grammar and plugin names the Agent Plugins name grammar
(workspacesdk.ValidatePluginName). Rows that fail are dropped and logged.

Skill descriptions from every source (personal, workspace, plugin) are now
sanitized when the index is rendered: prompt-sanitized, control runes and
whitespace collapsed to a single line, angle brackets escaped so a
description cannot close the available-skills block, and truncated by rune
(1024 for workspace and plugin skills, 4096 for personal skills).

codersdk.ChatContextResource gains PluginName and the plugin kind, so the
composer inserts /plugin/<plugin>/<name> for plugin skills and the context
indicator can label plugin manifest rows.

…ion, and env allow-list

Teach agentmcp to load Agent Plugins mcp.json files alongside the
legacy .mcp.json files it already handles.

New input types: ConfigSource{Path, Plugin *PluginScope} and
PluginScope{Name, Root, DataDir}. Manager.ReloadSources accepts
sources; Manager.Reload keeps its []string signature and wraps
ReloadSources with nil scopes. The file snapshot records the scope a
path was read under, so a plugin rename or data dir change with an
untouched mcp.json still reloads. ServerConfig gains Plugin and Cwd,
both part of the identity classifyServers compares, so a server moving
between a legacy file and a plugin is reconnected instead of kept.
ServerStatus gains PluginName so the catalog can carry a rejected
plugin entry next to a same-named legacy server.

Plugin files (plugin.go): the top level must be exactly $schema and
mcpServers with the 1.0.0 mcp schema URL, otherwise the file is
rejected and the plugin has no MCP servers. Entries require type in
{stdio, streamable-http, sse}; "http" is not accepted. stdio commands
are a single token, either a bare name or a ./-relative path that is
resolved against the plugin root, symlink-resolved, containment-checked,
and stored absolute. cwd accepts ./, ${PLUGIN_ROOT}, and ${PLUGIN_DATA}
prefixes and must resolve inside the root, or inside DataDir for the
last form. An entry env that sets PLUGIN_ROOT or PLUGIN_DATA is
rejected. HTTP URLs must be absolute, https unless the host is
localhost or a loopback IP, and carry no userinfo or fragment; headers
are passed as configured. Only ${PLUGIN_ROOT} and ${PLUGIN_DATA} are
expanded in args, env values, and cwd, in a single pass; plugin files
never go through os.Expand.

Plugin stdio launch: cmd.Dir is the resolved cwd, DataDir is created
0700 before launch, and the environment is the allow-listed subset of
the agent environment (PATH, HOME, USER, LOGNAME, SHELL, TERM, TMPDIR,
TZ, LANG, LANGUAGE, proxy and CA variables, LC_* and XDG_*) with HOME
falling back to the user's home dir, plus PLUGIN_ROOT, PLUGIN_DATA, and
the entry env. The updateEnv callback is not consulted for plugin
servers. PluginDataDir(home, name, root) is exported so the caller can
compute <home>/.coder/plugin-data/<name>-<sha256(root)[:12]>.

createTransport accepts "streamable-http" alongside "http".

Behavior changes for legacy .mcp.json servers:

1. Per-entry failure isolation. An invalid mcpServers entry (bad name,
   missing command and url, non-object) no longer drops the whole file.
   Valid siblings load, and the invalid entry is logged and surfaced in
   the catalog as a disconnected ServerStatus with Err, so it becomes an
   mcp_server resource with an error instead of vanishing. Unreadable
   or malformed files are still skipped whole. A plugin server whose
   name is already claimed by a legacy file or an earlier plugin is
   skipped with a visible Err entry; legacy duplicates keep the old
   silent first-wins behavior.

2. HTTP header origin pinning and redirect policy. Configured headers
   are attached only to requests whose scheme and host match the
   configured server URL, and only when the request does not already
   carry that header. The http.Client now refuses redirects to another
   origin, which includes any https to http downgrade, instead of
   following them.

The agent now feeds each valid plugin's mcp.json into the MCP engine.
mcpConfigSources composes the env-configured .mcp.json files followed
by one plugin-scoped source per plugin that ships an mcp.json, with
PLUGIN_DATA under ~/.coder/plugin-data. Both the startup reload and a
new snapshot subscriber use the same composition, and the subscriber
reloads only when the set of plugins changes, so catalog updates that
re-trigger the resolver do not loop.

ReloadSources re-checks the snapshot after joining a concurrent reload
and starts another one when its own sources were not the ones applied,
so the startup reload and the subscriber cannot drop each other's
servers.

MCP server resources declared by a plugin carry the plugin name and use
<plugin>/<server> as their source, so a plugin entry that lost a name
collision with a workspace server still appears with its error.

Plugin roots, ./-relative commands, cwd, and the plugin mcp.json are
canonicalized with EvalSymlinks. On Windows substituted drives that
call fails even for plain directories, which made every plugin
invisible and every plugin entry invalid on the Windows CI runner. A
path that is not itself a symlink now falls back to its cleaned form
when the filesystem cannot report symlink targets; a path that is a
symlink still has to resolve or is rejected.

The plugin stdio environment allow-list adds the variables a Windows
process needs to start (SystemRoot, ComSpec, PATHEXT, TEMP, profile and
application data directories) and compares names case-insensitively
there, since Windows environment names are case-insensitive.

Tests that create symlinks skip on Windows, matching the existing
agentcontext tests, and the fake plugin server binary carries the .exe
suffix Windows requires to resolve an extension-less command.

EvalSymlinks on a Windows substituted drive reports ERROR_PATH_NOT_FOUND
for paths that exist, which the previous fallback treated as a genuinely
missing path. The fallback now decides from Lstat alone: a missing path
or a symlink keeps the error, anything else uses the cleaned path.

The agent-level plugin MCP test waits longer for the discovery, reload,
and re-resolve chain and reports the pushed resources when it fails, so
a stall is attributable to a stage.

…eadonly

# Conflicts:
#	docs/reference/api/schemas.md

Match missing-path entry errors with fs.ErrNotExist instead of the
Unix message text, skip the Unix permission-bit assertion on Windows,
and copy rather than hard-link the fake server binary on Windows so
TempDir cleanup can remove it.

The sync goroutine subscribed to snapshot changes from inside itself,
so a snapshot broadcast before the goroutine was scheduled was never
observed and plugin MCP servers were not loaded until the next change.
Subscribe synchronously during init and examine the current snapshot
before the first wait.