Add ElizaOS upstream agent provider

[WiggidyW]

Summary

Add ElizaOS as a new upstream agent provider, alongside the existing
mock, openrouter, claude-agent-sdk, and codex (and the proposed
script). An ElizaOS agent is a real AI agent backed by the ElizaOS runtime,
exposed through the same shared agent interface as every other provider — so it
is a drop-in anywhere an agent is accepted (swarms, functions, fallback chains)
and participates in fallbacks identically.

This continues the philosophy from #235: agents are the glue that connects
software together, and every provider — deterministic code or a full agent
framework like ElizaOS — sits behind one common interface.

All ElizaOS configuration lives on the agent body

ElizaOS configures an agent through its character definition. For the
elizaos provider, that entire character configuration lives on the agent
body — the same way each existing provider's configuration (model identity,
decoding params, provider prefs, …) lives on its agent body today. Nothing about
the agent is configured out-of-band; the content-addressed agent definition fully
specifies the ElizaOS character, so two identical bodies hash to the same agent.

The agent body carries the full ElizaOS character surface, including:

• Identity & knowledge — name, username, bio, lore, knowledge
  (incl. RAG knowledge items), topics, adjectives.
• Behavior — system (system prompt), style (all / chat / post),
  messageExamples, postExamples, templates.
• Plugins — the primary extensibility surface. The list of ElizaOS plugins
  the agent loads (e.g. bootstrap, sql, the platform/client connectors, on-chain
  and tool plugins, etc.) plus each plugin's configuration, all declared on
  the agent body. Plugins bring the agent's actions, providers, evaluators, and
  client connectors, so "which plugins + how they're configured" is a core part
  of the agent's identity and must be part of the content-addressed body.
• Clients / connectors — the platform integrations the character runs on
  (in current ElizaOS these are themselves plugins), declared on the body.
• Model & provider settings — modelProvider / model + embedding model
  selection and any decoding/runtime settings.
• Secrets — per-agent settings.secrets. These reference credentials needed
  by plugins/clients; the body declares which secrets an agent needs (handling of
  the actual secret values is an open question below).

Behavior & interface

• Same completion shape and the same fallback semantics as other agents: if an
  ElizaOS agent fails, it proceeds to the configured fallbacks on that agent
  definition, just like any other provider.
• Content-addressed: the ElizaOS character config on the body is part of the
  agent's deterministic identity (same body → same agent id).

Open questions

• Runner / hosting. ElizaOS is a TypeScript/Node runtime. This likely needs a
  dedicated runner binary (mirroring objectiveai-claude-agent-sdk-runner and
  objectiveai-codex-sdk-runner), packaged into the release zip — a Node bundle
  rather than PyInstaller.
• Plugin loading & sandboxing. How plugins are fetched, version-pinned, and
  isolated; whether the plugin set is an allowlist or arbitrary npm packages.
• Version pinning. Pinning the ElizaOS core version and each plugin version so
  the content-addressed body stays reproducible.
• Secrets handling. How settings.secrets values are supplied/injected at
  execution time without baking them into the content-addressed body.
• MCP bridging. Whether the MCP tools an agent connects to are surfaced into
  ElizaOS via an ElizaOS plugin, so MCP works consistently across providers.

[WiggidyW]

Support both ElizaOS local and ElizaOS Cloud as execution modes for the
elizaos provider:

• Local — run the ElizaOS runtime ourselves via the dedicated Node runner
  binary (the runner/hosting open question above). Plugins load locally; we own
  the process lifecycle.
• Cloud — target the hosted ElizaOS Cloud service instead of a local runtime.

The agent body is identical in both cases — the same content-addressed ElizaOS
character config (plugins, settings, secrets, etc.). Local vs. cloud is an
execution/transport choice, not a change to the agent definition, so an agent can
move between the two without changing its identity (hash).

Implications to work through:

• Plugin availability/parity between what we can load locally and what Cloud
  supports.
• Secrets: injected into the local process vs. configured on the Cloud side.
• Auth/endpoint config for Cloud, kept off the content-addressed body (same
  bucket as the secrets-handling open question).