update implementation status of design documents

Author: lxsaah

docs/design/000-M1_error-feature-flags.md

@@ -1,5 +1,6 @@
 # 🎯 Design: Error Handling & Feature Flags (M1)
 
+**Status**: ✅ Implemented  
 **Milestone**: Core Foundation & Error Handling - M1  
 **Goal**: Establish unified error model and feature-flag architecture for AimDB's cross-platform async database  
 **Platforms**: `std` (Linux/macOS/Cloud), `no_std` (MCU/Embedded)

docs/design/001-M1_runtime-integration.md

@@ -1,5 +1,6 @@
 # 🚀 Design: Unified Runtime Integration & Executor Abstractions (M1.1)
 
+**Status**: ✅ Implemented  
 **Milestone**: Runtime Independence & Multi-Platform Execution (follow-up to M1)  
 **Goal**: Establish a clean, trait-based execution & time abstraction layer powering both `std` (Tokio) and `no_std` (Embassy) environments while keeping `aimdb-core` free of concrete runtime dependencies.  
 **Scope of Rework**: This document retrofits experimental work done on branch `8-runtime-adapter-integration-#1` (≈5K LOC delta) into a structured, incremental upstream plan.

docs/design/002-M1_pluggable-buffers.md

@@ -1,6 +1,6 @@
 # Design Document: Pluggable Per-Record Buffers
 
-**Status:** Draft  
+**Status:** ✅ Implemented  
 **Author:** AimDB Team  
 **Date:** October 11, 2025  
 **Issue:** [#27](https://github.com/aimdb-dev/aimdb/issues/27)  

docs/design/004-M2-api-refactor-source-tap-link.md

@@ -1,6 +1,6 @@
 # API Refactoring: `.source()`, `.tap()`, `.link()`
 
-## Status: Approved for Implementation
+## Status: ✅ Implemented
 **Date**: 2025-10-25
 
 ## Quick Summary

docs/design/005-M2-embassy-dynamic-spawning.md

@@ -1,5 +1,7 @@
 # Embassy Dynamic Task Spawning
 
+**Status**: ✅ Implemented  
+
 ## Problem Statement
 
 Embassy's executor requires all tasks to be statically defined with `#[embassy_executor::task]`. This creates a challenge for AimDB, which needs to dynamically spawn producer and consumer services registered via `.source()` and `.tap()` methods.

docs/design/006-M2-phantomdata-usage.md

@@ -1,6 +1,6 @@
 # PhantomData Usage in AimDB
 
-**Status**: Implemented  
+**Status**: ✅ Implemented  
 **Date**: 2025-10-28  
 **Author**: AimDB Team
 

docs/design/008-M3-remote-access.md

@@ -1,7 +1,7 @@
 # AimX v1: Remote Access Protocol Specification
 
 **Version:** 1.0  
-**Status:** Design Document  
+**Status:** ✅ Implemented  
 **Last Updated:** October 31, 2025
 
 ---

docs/design/009-M4-mcp-integration.md

@@ -1,7 +1,7 @@
 # AimDB MCP Integration Strategy
 
 **Version:** 1.0  
-**Status:** Design Document  
+**Status:** ✅ Implemented  
 **Last Updated:** November 2, 2025  
 **Milestone:** M4 - LLM Integration
 

docs/design/010-M4-mcp-notification-memory.md

@@ -1,21 +1,10 @@
 # MCP Notification Memory - Design Document
 
-## Problem Statement
-
-**Current Issue**: MCP servers can send notifications to clients, but LLMs (like Copilot, Claude) cannot access these notifications during conversations. This creates a disconnect:
-
-1. ✅ Subscriptions work - notifications are generated and sent
-2. ✅ MCP client receives notifications via stdio
-3. ❌ LLM has no way to access notification history
-4. ❌ LLM must poll via `get_record` instead of using subscription data
+**Status**: ✅ Implemented  
+**Impact**: Monitoring, alerting, and event-driven workflows are now fully supported for LLMs.
 
 ## Problem Statement
 
-**Status**: Implemented ✅  
-**Impact**: Monitoring, alerting, and event-driven workflows are impossible for LLMs despite having a working notification system.
-
-## Proposed Solution: MCP Notification Memory
-
 Create a persistent notification buffer that:
 1. Captures all notifications sent by the MCP server
 2. Stores them in a queryable format

docs/design/011-M4-schema-query.md

@@ -1,7 +1,7 @@
 # Query Schema Tool - Design Document
 
 **Version:** 1.0  
-**Status:** Ready for Implementation  
+**Status:** ✅ Implemented  
 **Created:** November 5, 2025  
 **Related Issue:** #43 (Phase 4 - Schema Query)  
 **Parent Doc:** [009-M4-mcp-integration.md](./009-M4-mcp-integration.md)