Add demo_plugin and plugin host integration tests

Minimal in-tree add-on (DP_HELLO) validates registry, ribbon merge, and try_dispatch. Five new lib tests; EntryKind gains PartialEq for test helpers.

docs/PR-plugin-host.md

@@ -51,7 +51,7 @@ cargo build
 cargo test --lib
 ```
 
-No domain plugin is registered in this branch; existing core tests should pass unchanged.
+A minimal **`demo_plugin`** add-on registers at compile time for smoke tests (`DP_HELLO` command, Demo Plugin ribbon tab). Remove or gate it before release if maintainers prefer zero in-tree add-ons.
 
 ## Review questions
 

docs/issue-78-comment.txt

@@ -0,0 +1,36 @@
+@HakanSeven12 @schoeller — following up with a concrete architecture proposal and an implementation ready for review.
+
+### Proposal
+
+I've drafted a **QGIS-style add-on model** on my fork:
+
+- **Spec:** [docs/plugin-architecture.md](https://github.com/mf4633/OpenCADStudio/blob/feature/plugin-host/docs/plugin-architecture.md)
+- **Scaffold:** [docs/plugin-template/](https://github.com/mf4633/OpenCADStudio/tree/feature/plugin-host/docs/plugin-template)
+- **Framework PR:** #80 — **host only, no Storm Sewer in core**
+
+**Three layers:** host core → add-on package (plugin.toml, ribbon, commands) → optional headless engine crate. Domain data lives on DWG entities (XDATA), not a proprietary project DB.
+
+**Phase 1 (PR #80):** in-process plugins via inventory::submit!(PluginRegistration), HostSession API, per-document plugin state, command routing without editing commands.rs.
+
+**Phase 2:** user install folder + dynamic .dll/.so with the same plugin.toml.
+
+### Storm Sewer (separate)
+
+Storm Sewer stays on a separate branch as the reference consumer — not in core: [feature/storm-sewer-module](https://github.com/mf4633/OpenCADStudio/tree/feature/storm-sewer-module).
+
+### Re: script languages (@schoeller, #29)
+
+Agree this shouldn't be either/or. Suggested sequencing:
+
+1. Native Rust add-ons + stable HostSession / ocs_plugin_api
+2. Python (or similar) as **bindings over that same API** — one extension surface, two authoring paths
+
+Phase 1 defers embedded scripting until the native API is stable.
+
+### Questions for maintainers
+
+1. ocs_plugin_api as a workspace crate with semver — OK?
+2. Should the main repo ship **zero** discipline modules, or optional built-ins for dev?
+3. Priority: extract API crate (1b) vs dynamic loading (2)?
+
+— Michael