fix: idempotent register guard + governance filter observability

[jlin53882]

Problem Description

During gateway startup, the memory-lancedb-pro plugin initialization block appears multiple times in logs (observed: 5× on a single boot), and governance filter decisions are opaque.

Issue 1: Repeated Initialization

Observed log:

22:51:38 [plugins] memory-lancedb-pro@1.1.0-beta.10: plugin registered
22:51:38 [plugins] mdMirror: resolved 18 agent workspace(s)
22:51:38 [plugins] session-strategy: using none
(repeats × 5)

Root cause: OpenClaw calls register() once per agent session boot. Without an idempotent guard, the full initialization (MemoryStore, embedder, hooks) runs every time.

Issue 2: Governance Filter Not Observable

Observed log:

memory-lancedb-pro: auto-recall skipped after governance filters (hits=6, dedupFiltered=0, stateFiltered=3, suppressedFiltered=3)

Only aggregate counts are logged. It is impossible to determine which entries were filtered, why, or what their scores were — requiring manual replay to debug.

Proposed Fix

See PR: #365

Fix 1: Idempotent register() Guard

Add a module-level singleton flag:

let _initialized = false;

register(api: OpenClawPluginApi) {
  if (_initialized) {
    api.logger.debug("memory-lancedb-pro: register() called again — skipping re-init (idempotent)");
    return;
  }
  _initialized = true;
  // ... full initialization
}

export function _resetInitialized() { _initialized = false; } // for test harness

Fix 2: Governance Filter Detail Logging

Add per-entry debug log when an entry is filtered:

api.logger.debug(
  `memory-lancedb-pro: governance: filtered id=${r.entry.id} ` +
  `reason=state(${meta.state}) score=${r.score?.toFixed(3)} ` +
  `text=${r.entry.text.slice(0, 50)}`
);

Testing

• Regression tests: ✅ All pass
• Local extensions: ✅ Gateway starts with initialized successfully only once

Environment

• OpenClaw: 2026.3.23-2
• memory-lancedb-pro: 1.1.0-beta.10
• OS: Windows_NT

[AliceLJY]

Thanks for the detailed analysis and fix, @jlin53882. Both issues are valid — repeated initialization wastes resources and the opaque governance filter makes debugging unnecessarily difficult. PR #365 addresses both with a clean idempotent guard and per-entry debug logging. We'll review it shortly.