Resolves #10410 partially (Bug 1 only — Bootstrap Idempotency Miss). Bug 2 (duplicate-wake delivery) deferred — needs more diagnostic data; reproducer preserved.

Context

During the bidirectional smoke test of the wake substrate post-#10404 merge, Claude (@neo-opus-ada) empirically observed two distinct bugs in the wake infrastructure. #10410 bundles them. This PR addresses Bug 1 only: bootstrap created a duplicate WAKE_SUBSCRIPTION node when the canonical sub already existed in SQLite but was missing from the in-memory cache (cross-restart scenario).

The Problem

WakeSubscriptionService.bootstrap's idempotency check iterates GraphService.db.nodes.items — the in-memory cache. WAKE_SUBSCRIPTION nodes from prior MC server instances are NOT pre-loaded into the cache after restart unless explicitly accessed via getAdjacentNodes. Cache iteration silently misses them, causing bootstrap to create a duplicate.

Empirical anchor: bootstrap created WAKE_SUB:e5f96999 (template-driven metadata) alongside existing WAKE_SUB:ca08d381 (stripped-empty metadata from prior session) because the cache lookup didn't surface the cross-restart sub.

The Fix

Query SQLite directly via GraphService.db.storage.db.prepare() — same approach as the bridge daemon's getActiveShapeCSubscriptions. The canonical SQLite source-of-truth is queried for any active sub matching the template tuple (agentIdentity, trigger, harnessTarget). If found, return status: 'existing'.

In-memory cache iteration is preserved as a fallback for test environments where db.storage.db (raw better-sqlite3) is not available. Anchor & Echo JSDoc explains the rationale and references #10410's empirical anchor.

Test Evidence

• All 25 existing tests in WakeSubscriptionService.spec.mjs pass (1.1s locally).
• The existing bootstrap › returns existing subscription if it matches template (idempotent) test continues to pass — cache and SQL both find the sub in the test environment; the SQL path is verified to work end-to-end.

A dedicated test for the cache-miss-but-SQLite-has-it scenario requires bypass infrastructure (manually deleting from cache while preserving SQLite). The empirical anchor in #10410's body documents the production reproducer; explicit coverage for cross-restart scenarios is a sensible follow-up if reviewers want it.

Deltas from ticket (Bug 1)

• Adopted SQLite raw query as primary lookup path (vs cache-only original)
• Added cache iteration as fallback for test compatibility
• Anchor & Echo JSDoc with #10410 reference

Out of Scope — Bug 2 deferred

Duplicate-wake delivery (citing same sub ID twice). Empirically observed: ONE inbound A2A message generates TWO wake notifications, both citing the SAME WAKE_SUB:ca08d381. Possible causes:

• Bridge daemon poll-loop iterates trace × sub pairs without per-(sub, trace) dedup
• Coalescing engine flushes twice within the 30s window
• Dual subs both fire (but observed evidence cites single subId twice, not one-each)

Needs concrete bridge-log stdout content from @tobiu to determine which root cause holds. Reproducer preserved in production substrate (Tobi keep-alive on WAKE_SUB:ca08d381).

Related

• #10402 — Phase 1 wake substrate self-healing (parent feature)
• #10404 — bootstrap action implementation (prior PR; this PR is its post-merge hardening)
• #10407 — silent-strip on validate-time write path (separate diagnostic, distinct from this LIST-path-resolved class)

Post-Merge Validation

• After merge + MC restart on @tobiu's checkout: call manage_wake_subscription({action: 'bootstrap'}) from a fresh session → confirm status: 'existing' (not 'created') when an active sub for the tuple already exists in SQLite
• manage_wake_subscription({action: 'list'}) post-bootstrap → only one sub per (identity, trigger, harnessTarget) tuple
• Continue Bug 2 diagnosis with bridge-log content; file Bug 2 fix as separate PR