feat: Index/Map Architecture — SQLite as index, .md files as content store

[chubes4]

Summary

Phase 1 of the Index/Map Architecture: SQLite becomes an index, markdown files become the only content store. No more duplicating post_content into SQLite.

• Boot now parses frontmatter only (skips file bodies), cutting boot I/O ~90%
• post_content is stored as empty string in SQLite for markdown-sourced posts
• New _markdown_file_index table maps post_id → file_path, file_mtime, file_size
• Driver lazy-loads content from .md files on SELECT queries that include post_content
• Write engine updates the file index after writing/deleting .md files

Changes

File	What
class-wp-markdown-storage.php	parse_file() gains $metadata_only flag; new read_frontmatter_only() (line-by-line, stops at closing ---); new public read_content_from_file() for lazy-loading; posts carry _source_file path
class-wp-markdown-loader.php	load_posts() calls get_all_posts(true), inserts empty post_content, creates & populates _markdown_file_index
class-wp-markdown-driver.php	query() intercepts SELECT results on wp_posts and resolves content via resolve_content(); file index cache loaded once into memory; update_file_index() / remove_from_file_index() for write-path
class-wp-markdown-write-engine.php	Updates file index after writing .md files; removes index entry on DELETE

Design doc

See wiki article: Markdown DB: Index Architecture Design (ID 128)

Testing

All existing functionality preserved — lazy-load is transparent:

• wp post list --post_type=wiki --format=count → 42 ✅
• wp post get 58 --field=post_content → full article content ✅
• wp intelligence wiki read karpathy-llm-wiki-pattern → full content ✅
• wp intelligence wiki tree → full tree ✅
• Regular posts and pages resolve correctly ✅

Next phases

• Phase 2: Optimized frontmatter-only parsing (already partially done — read_frontmatter_only())
• Phase 3: Persistent SQLite + manifest (warm boot in ~5ms)
• Phase 4: Smart resolution skipping (skip file reads for metadata-only queries)