[mattdjenkinson]

Problem
The dock panel puts its close button on top of the widget's top-right corner. Patch's chat now has a header with its own controls in that corner (datum-ui 3.4's vertical AssistantWorkspace), so the two buttons sit on top of each other.

Solution
Every portal.dock/project component is now mounted with an onClose prop. A widget that sets handlesClose: true in its manifest renders its own close control, and the panel then drops its overlay button. Widgets without the flag keep the overlay, so existing plugins are unaffected.

• DockProjectProperties.handlesClose and DockWidgetProps are defined in types.ts and validated in the manifest schema.
• LazyPluginComponent forwards optional componentProps to the plugin component.
• The dock's loading skeleton now matches the chat's vertical layout (top bar and empty state) rather than the old left rail.

DockWidgetProps lives here for now. It belongs in @datum-cloud/portal-plugin-sdk eventually, so plugins can import the type instead of copying it.

Rollout
Merge and deploy this before releasing the assistant plugin change that sets handlesClose (milo-os/assistant#113). An older portal ignores the flag and keeps its overlay button, which would then sit on top of the chat's new-chat button.

Related: datum-cloud/datum-ui#228

Test plan

• bun run typecheck, eslint, prettier
• bun test app/modules/plugins: 221 pass, including 2 new manifest schema tests (handlesClose accepted, non-boolean rejected)
• With the updated assistant plugin: the dock shows a single close button (in the chat header), and it closes the panel
• A dock widget without handlesClose still gets the overlay close button

[github-actions]

🧪 Test Summary

Job	Status
Bun Unit Tests	✅ success
E2E Regression (0)	✅ success
E2E Regression (1)	✅ success
E2E Regression (2)	✅ success
E2E Regression (3)	✅ success
E2E Smoke	✅ success
Unit Tests	✅ success

View workflow run

_{Need another run? Use Re-run failed jobs: one shard costs a few minutes, the whole workflow about 26.}