refactor: clarify plugin process ownership and runtime topology

[limityan]

Summary

• Reserve Plugin Host for the supervised Node/Bun child process that executes third-party JS/TS.
• Rename the Rust-side crate and API to Plugin Runtime Client so the caller is not mistaken for the process owner.
• Define when compatible plugins share a Host, when they require separate processes, and how updates, failures, and cleanup work.
• Incorporate the layered Local Agent Host design for multiple GUI, TUI, Remote, CLI, and SDK instances while retaining one Agent Runtime behavior model.
• Replace large all-in-one diagrams and dense prose with focused views, short labels, direct wording, and small comparison tables.

Runtime topology

Surface	Default deployment	Plugin process boundary
GUI / TUI / local Remote	Planned shared Rust Local Agent Host	Compatible plugins reuse supervised Node/Bun Plugin Hosts owned by that Rust process
One-shot bitfun exec	Embedded Rust Runtime	Own child-process tree; no transparent sharing with Local Agent Host
Public Agent SDK	Private Rust SDK Host	Own child-process tree; explicit authorization is required to access user Local Host state
Remote workspace	Runtime on the remote machine	Plugin Host also runs on the remote machine

The Local Agent Host and shared package-plugin process model remain planned architecture. The current managed bitfun.plugin.json path is still validation, lifecycle records, diagnostics, and static custom-tool preview; the existing standalone .js tool worker remains a narrow per-script implementation.

Ownership and isolation

• PluginRuntimeClient owns typed request/response reliability facts, not OS processes or capability state.
• ScriptToolRuntime / services remains the physical process owner and reports process membership and Host startup identity.
• Tool, Hook, Config, Permission, Session, Event, and TUI owners still validate and commit their own facts.
• Plugins share a Host only when the execution machine, OS user, backend, native dependencies, sandbox, network, environment, and credentials are compatible.
• A shared Plugin Host failure affects its hosted plugin instances; the Rust Runtime remains alive.
• The design does not introduce another plugin execution object, registry, lifecycle, or version counter. Existing source owners identify plugin instances, and capability owners manage contributions.
• Each Host has its own process connection. Updates perform static checks first, settle old calls, and ask the existing process service to stop the old Host. New plugin code loads only after OS process handles confirm that the old process tree is gone. Calls stay unavailable during the restart; messages from replaced connections are ignored.
• Disabling one member of a shared Host replaces the whole Host with the remaining approved members. Security revocation stops the old Host before restoring any remaining plugins, so background JS cannot continue after its visible contribution disappears.
• Every persisted Session has one writer. The existing Session persistence owner grants and transfers write access; different Sessions may proceed concurrently, while an old Host cannot keep writing after takeover.

API impact

The Rust Runtime SDK preview version moves from v1 to v2 because the public preview error variant changes from UnsupportedPluginRuntimeHostBinding to UnsupportedPluginRuntimeClientAvailability. No compatibility alias preserves the misleading Rust-side Host term.

Documentation and readability

• Replaces plugin-runtime-host-design.md with the canonical plugin-runtime-design.md.
• Adds local-agent-host-multi-instance-design.md for the layered multi-instance runtime topology.
• Keeps current implementation, planned architecture, process ownership, and product delivery status distinct across product, Runtime, CLI, OpenCode compatibility, and SDLC documents.
• The 32 retained Markdown files in the PR contain 64 Mermaid diagrams. Each diagram focuses on one topology, decision, lifecycle, or event-flow question; the largest diagram is 24 lines.
• Replaces abstract platform jargon with direct behavior descriptions. Exact code identifiers remain only where they are needed to match current contracts and are explained beside their use.
• Restores critical concurrency and protocol facts that must not be lost during simplification: per-connection request ownership, single Session writers, SDK Runtime API routing, and CLI single-final-event ordering.

Validation

• cargo test -p bitfun-runtime-ports -p bitfun-plugin-runtime-client -p bitfun-opencode-adapter -p bitfun-agent-runtime -p bitfun-product-capabilities
• cargo test -p bitfun-runtime-ports --test plugin_runtime_diagnostics_contracts
• cargo check --workspace
• node scripts/core-boundaries/self-test.mjs
• node scripts/check-core-boundaries.mjs
• pnpm run check:repo-hygiene
• Browser parse of all 64 Mermaid diagrams with Mermaid 11
• Relative-link and heading-anchor validation across all 30 readability-updated Markdown files
• Independent adversarial reviews for architecture consistency, process isolation, protocol behavior, and human readability

cargo check --workspace retains only existing MCP deprecation and Windows CLI conditional-code warnings. No product performance threshold or measured runtime metric changes in this PR; the Local Agent Host document defines the measurements required before Host-backed delivery can be claimed.