feat(types): pluggable agent-type registry

[lucianlamp]

Summary

Adding an agent type to agmsg is currently a hardcoded, multi-file edit. The most
recent addition — OpenCode (#136) — touched 8 files, adding per-type case
arms in whoami.sh, join.sh, spawn.sh, and delivery.sh plus a template and
docs. Every new type repeats that scatter, and the type list drifts between files.

This PR makes a type data: a small read-only manifest at
types/<name>/type.conf describes detection, the whitelist, spawn, and delivery
routing, and the scripts read it instead of hardcoded case arms. The six
existing types are converted with zero behavior change — the full suite stays
green (296 → 311 with the new registry tests).

What changes

• New scripts/lib/type-registry.sh — discovery + a per-key reader.
  Manifests are read-only key=value data, never sourced (a third-party
  type cannot execute code; an adversarial cli=$(touch X) is read as a literal).
• types/{claude-code,codex,gemini,antigravity,copilot,opencode}/type.conf — the
  six built-ins as manifests (detect / detect_proc, cli / spawnable,
  hooks_file, monitor, template).
• whoami.sh — detection reads detect= (env vars) and detect_proc= (process
  globs); sorted order preserves the claude-code < codex < gemini precedence.
• join.sh — the whitelist validates against the registry.
• spawn.sh — the spawnable set and launch binary come from the manifest; the
  error lists the computed spawnable set.
• delivery.sh — resolve_hooks_file reads hooks_file= (the per-type hook
  format in apply_settings_* is unchanged).
• install.sh / tests/test_helper.bash — ship/copy types/.
• docs/agent-types.md — the manifest schema + "adding a type = manifest +
  template".

Adding a type, after this PR

Drop types/<name>/type.conf + templates/cmd.<name>.md. whoami, join, and
spawn pick it up with no further edits. (A genuinely new delivery hook format
still needs an apply_settings_<name>; reusing a format needs no code.)

Extensible to external add-on types

Beyond built-in CLI types, a type can declare a node launcher so an agent
runtime ships entirely outside the agmsg tree and plugs in with no core edits:

• spawn=<launcher>.mjs — spawn.sh launches it via Node with four universal
  flags (--name --team --project --initial-input); all type-specific config is
  the launcher's own default/env, so core names no add-on.

Types are always selected explicitly (spawn <type>), so an add-on never
hijacks a built-in's spawn name.

Real-world example

The node-launcher plug point is demonstrated by a real, separately-released add-on:

• Add-on: lucianlamp/agmsg-codex-app-server
  — a Codex runtime (app-server + host-managed turn-trigger watcher + a
  scroll-region TUI) that installs on top of a stock agmsg purely via the
  registry (a types/codex-app-server/ manifest with spawn=), touching no
  built-in; spawned explicitly as spawn codex-app-server <name>.
• Reference fork (this branch): lucianlamp/agmsg
  — a stock install of this PR with the add-on dropped on top.

The add-on lives in its own repo and is not part of this PR — it is only the
proof that the mechanism hosts external types cleanly.

Testing

• Full existing suite green and behavior-unchanged for the built-ins (296/296).
• New tests/test_type_registry.bats: discovery, the key reader + default,
  detection-manifest values + precedence + end-to-end via whoami.sh, the
  spawnable set, the node-launcher (spawn=) plug point (an in-tree fixture, so
  the mechanism is not dead code), a no-hardcoded-type-name guard, and a guard
  that manifests are data (the adversarial $(touch …) runs nothing). 311/311.
• End-to-end: the linked add-on installs onto a stock build of this branch and
  spawn codex-app-server produces a boot command that runs its Node launcher
  with the universal flags.

Scope / non-goals

• No new built-in types, runtimes, or delivery semantics — only the routing
  source changes (case → manifest).
• The per-type delivery hook format code (apply_settings_*) is unchanged.
• The codex-app-server add-on is external and out of scope here.

[fujibee]

@lucianlamp

Thanks for this — and the OpenCode (#136) "8-file scatter" framing is exactly the drift we want to kill. We're landing this direction in #181 (the 1.1.0 "restructure agent types" branch): each type becomes a read-only type.conf manifest plus behavior plugs (delivery / session-start), with dispatch reading the manifest instead of per-type case arms — very close to your sketch. Since #181 is already mid-flight and touches these files broadly, we're consolidating the registry work there rather than running two parallel reshapes. Your manifest-design input on #181 as it firms up would be very welcome. Referencing this PR from #181.

[fujibee]

@lucianlamp

Closing as superseded by #181, which landed the pluggable agent-type registry on main — your design (a per-type type.conf manifest discovered from data instead of hardcoded case arms, killing the OpenCode-style 8-file scatter) is exactly the shape it took. Thank you for the proposal and the clear framing; it directly shaped the direction. Adding a type is now just a manifest + plugs — e.g. #131 (Cursor) drops in as a single directory.