docs: add cpex Rust specification

[terylt]

Summary

Adds the public API spec for CPEX's Rust core (cpex-core + cpex-sdk). Companion document to
cpex-go-spec.md, but covering the in-process Rust path: how to author a plugin, how to embed
the manager, and what the framework guarantees.

Audience

• Plugin authors writing plugins that compile into the same binary as the host.
• Embedders integrating PluginManager into a Rust application.

(Go integrators should keep using cpex-go-spec.md — that doc covers the C ABI surface, this one covers the typed
Rust API one layer below it.)

What's covered

• Architecture & lifecycle — how PluginManager, the registry, and the executor fit together.
• Plugin authoring — the Plugin, HookHandler<H>, HookTypeDef, and PluginPayload traits, with the borrow /
  clone / capability semantics spelled out.
• Quick reference — one-line cheatsheet for the most common API calls.
• Extensions, CMF payloads, YAML config, factories — sections 7-10 walk through each subsystem.
• Sample plugin (§11) — end-to-end worked example, from payload to factory to YAML to invoke.
• State, errors, threading, testing, build — sections 12-16, the operational stuff.
• Dynamic plugin loading (§17, design note) — architectural sketch for how out-of-process plugins (C ABI,
  hypothetical Rust cdylib) work without changing the typed plugin-author API. Marked clearly as design-only where
  things aren't shipped yet.
• Gaps (§18) — features present in the Python framework that the Rust core doesn't cover yet.

What this is not

• Not a tutorial — it assumes Rust fluency and familiarity with CPEX as a concept.
• Not a runtime/internals doc — only the public API. Internal modules (executor, routing cache, etc.) are referenced
  but not specified.
• Not an FFI/C ABI reference — that's cpex-go-spec.md.

Review focus

• Does §6 (Plugin Authoring) give you enough to write a plugin without reading source?
• Does §11 (Sample Plugin) match what you'd actually write today?
• Does §17 (Dynamic Loading) describe an architecture you're comfortable committing to, given that the Rust-cdylib
  path is design-only?
• Anything missing that you'd expect a plugin author or embedder to ask?

Test plan

• Renders cleanly in markdown preview
• All cross-section references (§N) resolve
• Code samples match current crates/cpex-core symbols (spot-check register_handler, HookTypeDef,
  define_hook!, PluginResult constructors)

[araujof]

LGTM