fix: register active runtime and allow dreaming config

[holeshotclaw]

Summary

• register an active memory capability runtime so OpenClaw can discover the plugin as the selected backend
• expose search/read/status probes through that runtime bridge
• allow a top-level dreaming config block so OpenClaw sidecar dreaming can be configured when this plugin owns the memory slot
• add regression coverage for the manifest key and runtime registration

Testing

• node test/plugin-manifest-regression.mjs

[rwmjhb]

This PR currently has merge conflicts with the base branch (mergeable=CONFLICTING per GitHub). Deep review is paused until the branch rebases cleanly — reviewing now would:

1. Give feedback against a branch you'll have to rewrite anyway
2. Produce findings that may be invalidated once conflicts are resolved
3. Potentially miss issues introduced by the conflict resolution itself

Please:

1. Rebase this branch onto the latest base (or merge the base into this branch)
2. Resolve all merge conflicts
3. Push the rebased branch

Once that's done, the review pipeline will pick it up automatically on the next scan and do a full pass. Thanks for your patience.

[rwmjhb]

Requesting changes because the new runtime registration can crash hosts that do not expose this API.

1. index.ts:2034 — api.registerMemoryCapability(...) is called unconditionally.
   The existing test/recall-text-cleanup.test.mjs harness has no registerMemoryCapability method (test/recall-text-cleanup.test.mjs:37-58), and npm test fails at test/recall-text-cleanup.test.mjs:221 with TypeError: api.registerMemoryCapability is not a function. More importantly, this suggests older or alternate OpenClaw hosts can fail plugin registration before lifecycle hooks/services are registered. Please feature-detect the method, add a compatibility fallback, or make the call safely optional.

A few non-blocking follow-ups:

• index.ts:2039-2040: getMemorySearchManager() eagerly performs store.stats() and embedder.test() before any manager method is used. That adds DB/network latency to manager construction and can return manager: null even when search/read paths would otherwise work. Please compute status/probe data lazily inside status() / probe methods.

• index.ts:2083-2087: search results report startLine: 1, but readFile() returns a synthetic markdown document where memory text starts after the metadata header, around line 8. Citations can point at # Memory ... instead of the matched text. Please offset the returned line range or make search/read line numbering consistent.

• index.ts:2120-2122: probeVectorAvailability() only calls embedder.test(), so it reports embedding health rather than vector-store/retrieval health. Please probe the store/retriever path as well, or rename the probe semantics.

The runtime registration is the right direction, but the host API compatibility crash needs to be fixed before merge.

[rwmjhb]

This PR currently has merge conflicts with the base branch (mergeable=CONFLICTING per GitHub). Deep review is paused until the branch rebases cleanly — reviewing now would:

1. Give feedback against a branch you'll have to rewrite anyway
2. Produce findings that may be invalidated once conflicts are resolved
3. Potentially miss issues introduced by the conflict resolution itself

Please:

1. Rebase this branch onto the latest base (or merge the base into this branch)
2. Resolve all merge conflicts
3. Push the rebased branch

Once that's done, the review pipeline will pick it up automatically on the next scan and do a full pass. Thanks for your patience.