refactor(plugins): move the Project domain out of core into the standalone @flybot/project plugin #2830

Written-by: Chief

Owner: Dev
Reviewer: Reviewer

The Project domain still lives in core/src/host/project-*.js (Project State, the Project board, the Project's own Chief, the team dossier, the metrics, the assistant), although plugins/{social,tree,workflow,timeline} are peer @flybot plugins already. The user asked for it on 2026-11-11T02:00Z, with the sidebar "项目" row named as the entry point that must keep working.

What "moved" means

• plugins/project (@flybot/project) with the same package shape as its four peers: package.json (exports ./client, dsh.client.platform=web, dsh.bundle.patch), index.js apply/destroy, cordis.patch.yml, README, src/, test/.
• The domain's modules and its ten test files move with it: no copy, no second rendering, core/ keeps only the runtime seams it already calls by name (rt.projectBoard/Chief/Team/Assistant) and a host seam handing the plugin the live runtime plus the shared pure helpers.
• The owner switch project joins core/src/host/plugins.js; with it off the whole domain registers nothing (no tool, no seam), and with it on the project_state / project_digest tools and the four seams are present — both states have to be shown, not just the on one.
• install:doctor and the CI plugin matrix learn the fifth plugin; plugins/project runs its own suite in CI like its peers.

Acceptance

1. The moved suites keep their case counts and pass before and after the move (parity table in the pull request).
2. New boundaries carry a red-first proof: with each new piece restored to its pre-change form the pinning test is red, and green again once restored — the switch list, the doctor's package list, and the plugin's own apply().
3. pluginEnabled('project') true and false both demonstrated on a real runtime.
4. Behavior unchanged: same reads, same refusals, same strings for everything the user sees.

Implementation: in flight — the pull request is open. Do not pick this up as new work.