Friends' Bots shows raw "Unknown FlyBot endpoint social/remote-bots" when the social plugin failed to start #68

Part of #5 (@flybot/social).

Environment

• macOS arm64, FlyBot core + @flybot/social + @flybot/tree installed from FlyBot#main (a48fd86) via npx -y @deepseek-ai/dsh@0.2.0-rc.2 plugin --profile web add ..., run with dsh web --port 3080.
• Bot Social server: self-hosted, reachable; onboarding initially fails HTTP 409 (the home handle derived from displayName — e.g. Danyang → danyang.home — already exists on the server from an earlier onboarding whose connector token was lost).

Steps to reproduce

1. Point flybot-social at a Bot Social server where onboard fails (e.g. handle_taken 409 as above), or otherwise make the plugin's start fail.
2. Start dsh web and open the UI. The social client bundle still loads (the plugin is enabled), so the sidebar renders the "Friends' Bots" section.
3. Watch the section.

Actual

Friends' Bots shows the raw host error in red:

Unknown FlyBot endpoint social/remote-bots

The only trace of the real cause (flybot-social: start failed: Bot Social onboarding failed: HTTP 409) is on stderr in the terminal; the UI never mentions it.

Expected

• The section degrades gracefully: hidden, or showing a friendly "Social is not running: <reason>" state — not the host's internal not-found message.
• The plugin start failure is visible somewhere a user can find it (diagnostics / a notice), including which handle was taken for the 409 case.

Root cause

• Handler registration happens inside createSocial (plugins/social/src/social.js:630, flybot.api.handle('social/remote-bots', ...)), which only runs after startSocial succeeds. On start failure nothing is registered.
• The dispatcher throws when no handler exists: Unknown FlyBot endpoint ${name} (bot/not-found) at core/src/host/hooks.js:627.
• The client renders whatever errorText(e) returns: plugins/social/client.js:98 (call('social/remote-bots', ...) → setError(...)).

Verified this is exactly "handler not registered": once onboarding succeeds (I changed displayName so a fresh home was created), POST /api/bot with {"endpoint":"flybot/social/remote-bots"} returns {"ok":true,"value":{"homes":[]}} on the same install.

Suggested direction (for discussion, not prescriptive)

• Client: treat bot/not-found on social/* calls as "social unavailable" and render an idle/hidden section (same for the settings call, which currently swallows errors with () => {}).
• Host/plugin: surface plugin start failures through diagnostics so the UI can point at the real cause instead of a missing endpoint.