@flybot/social fails to import when installed: face-rooms.js reaches into core/src/shared via a repo-relative path #155

Found by deploying main to a real DSH profile (plugin installed with dsh plugin --profile web add "github:…#main&path:/plugins/social"): the whole plugin fails to activate.

Observed

dsh: warning: 1 entry did not activate
flybot-social (@flybot/social): failed to import

Importing the installed package directly:

Error [ERR_MODULE_NOT_FOUND]: Cannot find module '<profile>/node_modules/core/src/shared/face-title.js'
  imported from '<profile>/node_modules/@flybot/social/src/face-rooms.js'

Root cause

plugins/social/src/face-rooms.js:14 (face-to-face work, #107/#109/#132):

import { formatFaceRoomTitle } from '../../../core/src/shared/face-title.js'

That path only resolves inside the monorepo checkout (core/ sits beside plugins/). In an installed plugin the specifier walks out of @flybot/social into node_modules/core/…, which does not exist (the package is ds-bot, and it does not export that file). CI misses it because tests run in the repo where the path happens to resolve. This breaks the packaging invariant that a plugin ships self-contained under its files.

Scope

• git grep '\.\./\.\./\.\./' main -- plugins/ shows exactly one shipping offender: plugins/social/src/face-rooms.js:14 (a similar import in plugins/social/test/social.test.js is test-only and never ships).
• core/src/host/room-membership.js also uses the helper, but stays inside core, so its relative import is fine.

Suggested direction

Vendor the small, dependency-free helper into plugins/social/src/ and import it locally (plugins deliberately import nothing from ds-bot at runtime), plus a packaging regression test that scans plugins/social/src/** for import specifiers resolving outside the package — red on current main, green after the fix.