Plug in feature and example we flourish plugin

[LokiMetaSmith]

Implementation of Modular Integration Plugin System and WeFlourish Integration

This PR introduces a modular plugin architecture to the OHM platform, enabling external integrations (such as WeFlourish) to operate as self-contained modules without increasing coupling in the core codebase.

Key Changes:

• Plugin Manager: Added PluginManager to handle discovery, lifecycle hooks (startup/shutdown), and dynamic route registration.
• Plugin Architecture: Plugins are now located in src/plugins/, featuring standardized structures (routes, services, and private configuration via pydantic-settings).
• Core Integration: Updated src/core/main.py to trigger plugin lifecycles and register routes during application startup.
• WeFlourish Integration: Implemented the initial WeFlourish RFQ integration using the new plugin system.
• Documentation: Added docs/development/plugins.md to guide future plugin development and standard best practices.

New Dependencies:

• Added pydantic-settings to pyproject.toml to support isolated plugin configurations.

This structure keeps the core agnostic and ensures that integrations follow consistent development patterns.

[touchthesun]

Thanks for this, @LokiMetaSmith — this is a substantial, well-organized contribution, and the core instinct is exactly right: keep integrations out of the core and behind a consistent, documented pattern. The BasePlugin/PluginManager design is clean, it's tested, and docs/development/plugins.md is a great touch. We'd like to land the mechanism — with some changes so it lines up with where we're taking the plugin architecture.

For context: we've been putting together our own specification for the plugin system in parallel, so this review is about reconciling your implementation with that direction rather than any problem with the code quality.

What's working well

• Explicit ACTIVE_PLUGINS allowlist + in-tree src/plugins/ + in-process loading — this matches our trust model almost exactly (first-party, vetted-by-review, no arbitrary auto-discovery). 👍
• Clean lifecycle (initialize / on_startup / on_shutdown) and isolated per-plugin config via pydantic-settings.
• A real, tested example integration rather than a bare abstraction.

The main reframe: two classes of plugin
We think of plugins in two distinct shapes, and it affects the contract:

1. Data-source / interop adapters — bring external data into OHM's model (fetch → normalize to OKH/OKW). This is our highest-priority extension point: generalizing our existing Maps of Making integration so others (e.g. Appropedia, fablabs.io) can plug in design/facility sources. Your current framework doesn't cover this class — it's oriented around mounting API routes, which is a different axis.
2. Business-logic / connector plugins — sit on top of OHM, consuming its data or bridging to external tools (RFQ, cost estimation, etc.). Your WeFlourish integration is a great example of this class, and route-mounting is a reasonable mechanism for it.

So: the framework serves class (2) well, but we don't want it to become the only plugin concept and leave class (1) as a separate parallel system. We'd like the registration/lifecycle to be shared, with class (1) adapters carrying a typed → OKH/OKW contract.

Requested changes before re-review

1. Split the PR. Please separate the framework (base.py, manager.py, main.py wiring, docs) from the WeFlourish/RFQ integration. We'd like to evaluate and iterate on the mechanism on its own; the partner integration can follow once the framework is settled.
2. Keep partner/domain shapes out of core. src/core/models/rfq.py puts an RFQ model in the core — that undercuts the "core stays agnostic" goal. RFQ-specific models should live inside the plugin. (Heads-up: RFQ is currently shelved on our side pending a product decision, so please don't make the framework depend on it.)
3. Reconcile with the data-source axis. Let's make sure there's one plugin concept. Happy to work with you on a small typed contract for data-source adapters that reuses your BasePlugin registration/lifecycle.
4. Provenance + untrusted-by-default for any data-importing plugin. Anything that imports records must attach its source/provenance, and imported data should be treated as unverified so downstream (matching/browse) can filter or down-weight it. Not needed for WeFlourish, but it belongs in the base contract for class (1).
5. Capability declaration & versioning. Two things to add to the contract: (a) plugins declaring the capabilities they need (network, storage-write, read-only, …) toward least-privilege, and (b) a plugin-API version so we can manage compatibility as the contract evolves.

Smaller notes

• Consider what happens when a listed plugin fails to import mid-list — right now discover_and_load logs and continues, which is reasonable, but we should decide whether a failed active plugin should hard-fail startup in some environments.
• A scaffold/template plugin (or a create-plugin helper) would make external authorship as easy as we want it to be — the docs are a great start here.

To be clear on scope: unvetted third-party plugins / sandboxing are explicitly out of scope for now — in-tree + allowlisted + reviewed is the model we want at this stage, which your design already fits.

Really appreciate the work here — this is a strong foundation and we'd like to get it in. Happy to pair on the data-source contract so class (1) and class (2) share one clean framework. 🙏