feat(extensions): add host-owned external integration policy

[limityan]

Summary

This PR establishes a Host-owned external-integration control plane, with OpenCode as the first registered ecosystem while keeping the policy and adapter boundary ecosystem-neutral. Users can keep the recommended low-friction policy, choose discovery-only or disabled behavior, and override individual capabilities at global or project scope.

The same versioned policy, typed error contract, and public read model serve Desktop, CLI/TUI, Server Web, and Peer Host paths. Remote operations are evaluated by the workspace-owning Host; unavailable, untrusted, or read-only paths fail closed without falling back to another device's local files.

Product experience

• Recommended defaults keep prompt commands lightweight while tools, subagents, and MCP servers remain confirmation-gated according to capability risk.
• Global and project scope, inheritance and overrides, internal and external origin, source health, effective policy, configuration location, and read-only state are presented in compact settings surfaces.
• Users can enable, disable, or limit external integration without repeated modal prompts. Background discovery refreshes only while needed and uses capped backoff so slow remote hosts do not create persistent request pressure.
• MCP and Skills surfaces clearly distinguish external content from BitFun-owned content. External MCP entries show ecosystem, scope, status, source location, and transport without exposing raw diagnostic details.
• Pending, degraded, stale, unsupported, read-only, and unavailable states remain distinct. Malformed or partial Host responses are normalized only where fields are legitimately optional; invalid shapes surface a safe typed failure instead of appearing as an empty catalog.
• Unknown skill ownership fails closed. Destructive deletion is permitted only for eligible BitFun-owned, non-built-in skills and is enforced again at the Host boundary.
• Responsive behavior, keyboard semantics, independent detail controls, and compact icon actions preserve the existing design language on desktop and narrow layouts.

Architecture and safety

• Product assembly owns ecosystem registration and capability selection. Concrete provider identity remains private to the registered adapter rather than becoming a stable public facade.
• The adapter seam is versioned and intentionally thin. It can later support additional external ecosystems or a first-party marketplace without exposing unstable BitFun internals as a public SDK in this PR.
• Active command, tool, subagent, and MCP capability sets are isolated by ecosystem and source. External failures cannot silently disable or replace core BitFun behavior.
• Unknown minor fields survive read-modify-write. Unsupported future schema majors are retained opaquely, excluded from public snapshots, and recoverable only through explicit backup-and-reset behavior.
• Preference mutations share optimistic revisions, preventing Desktop, CLI, Server, and Peer Host actions from silently overwriting each other.
• Runtime invocation rechecks current policy. Disabling a capability retires its active routes and MCP runtime state.
• Typed operation errors carry stable codes, retryability, and correlation identifiers across Host boundaries. Logs use bounded categories and never include configuration payloads, raw internal errors, private workspace paths, or executable prompt content.
• Cross-host snapshots exclude executable templates, prepared runtime payloads, future-schema raw data, and private local paths.
• Server browser access uses an exact Origin allowlist, GET-only CORS behavior, bounded WebSocket input, and early rejection of unsupported writes.
• Repository boundary governance protects the intended public API and product-full ownership instead of relying on broad exceptions.

Scope

This PR completes the OpenCode-first compatibility control plane and its cross-surface user experience. It does not add a first-party plugin marketplace, extension bundle format, automatic third-party package execution, or public developer SDK. The internal versioned adapter boundary and ecosystem registry preserve those future options without coupling the current product to them.

Validation

• cargo check --workspace: passed
• cargo test -p bitfun-core -p bitfun-desktop: passed; core reported 1,245 passed and 1 ignored, with desktop and related integration targets passing
• cargo test -p bitfun-server: 11 passed
• Focused Web API, policy UI, MCP, collection-item, and skill-source tests: 5 files, 52 passed
• MCP pending, workspace-switch, and capped-backoff behavior: 11 passed, including an independent rerun
• Web type check and focused lint: passed with no errors
• i18n audit: passed with 0 warnings
• Core boundary check and boundary self-tests: passed; 16 self-tests passed
• Repository hygiene and git diff --check: passed
• Desktop and narrow-layout visual review covered populated, read-only, degraded, malformed-config, detail-expanded, and empty states; no remaining clipping, misleading controls, or crash state was found
• Independent final architecture review: no remaining P0, P1, or P2 findings
• Independent final product and accessibility review: no remaining P0, P1, or P2 findings