feat: complete HTML-first architecture implementation (Phase 1 & 2)

Major architectural simplification removing content type complexity:

Database Schema:
- Remove 'type' field from content and content_versions tables
- Simplify to pure HTML storage with html_content + original_template
- Regenerate all sqlc models for SQLite and PostgreSQL

API Simplification:
- Remove content type routing and validation
- Eliminate type-specific handlers (text/markdown/structured)
- Unified HTML-first approach for all content operations
- Simplify CreateContent and UpdateContent to HTML-only

Backend Enhancements:
- Update enhancer to only generate data-content-id (no data-content-type)
- Improve container expansion utilities with comprehensive block/inline rules
- Add Phase 3 preparation with boundary-respecting traversal logic
- Strengthen element classification for viable children detection

Documentation:
- Update TODO.md to reflect Phase 1-3 completion status
- Add WORKING_ON.md documenting the architectural transformation
- Mark container expansion and HTML-first architecture as complete

This completes the transition to a unified HTML-first content management system
with automatic style detection and element-based behavior, eliminating the
complex multi-type system in favor of semantic HTML-driven editing.

TODO.md

@@ -10,12 +10,15 @@
 - **Authentication System**: Mock (development) + Authentik OIDC (production)
 - **Build-Time Enhancement**: Content injection from database to static HTML
 - **Development Workflow**: Hot reload, auto-enhanced demo sites, seamless testing
+- **Container Transformation**: CLASSES.md syntactic sugar - containers auto-expand to viable children
 
 ### **🏗️ Architecture Achievements**
 - **Zero Configuration**: Just add `class="insertr"` to any element
 - **Framework Agnostic**: Works with any static site generator  
 - **Performance First**: Regular visitors get pure static HTML with zero CMS overhead
 - **HTML-First**: No lossy markdown conversion - perfect attribute preservation
+- **Unified System**: Single HTML preservation path for all content types
+- **Element-Based Behavior**: Automatic editing interface based on HTML tag semantics
 
 ---
 
@@ -24,7 +27,7 @@
 ### **🔴 Phase 1: Editor Integration Polish** (High Priority)
 
 #### **Frontend-Backend Integration**
-- [ ] **Editor-API Connection**: Wire up StyleAware editor saves to actual HTTP API
+- [x] **Editor-API Connection**: StyleAware editor saves successfully to HTTP API
 - [ ] **Error Handling**: Proper error states, loading indicators, offline handling
 - [ ] **Content Validation**: Client-side validation before API calls
 - [ ] **Save Feedback**: Professional save/error feedback in editor interface
@@ -49,7 +52,40 @@
 - [ ] **Content Approval**: Editorial workflows and publishing controls
 - [ ] **Performance Monitoring**: Analytics and optimization tools
 
-### **🟢 Phase 3: Advanced CMS Features** (Low Priority)
+### **✅ Phase 3: Container Expansion Intelligence** (Complete)
+
+#### **Element Classification and Boundaries**
+- [x] **HTML Semantics Approach**: Use HTML tag semantics for block vs inline detection
+- [x] **Framework Agnostic Processing**: No special framework container detection
+- [x] **Boundary Rules**: Only `.insertr` elements are boundaries, traverse all other containers
+- [x] **Block/Inline Classification**: Clear rules for when elements get `.insertr` vs formatting
+
+#### **Implementation Status** 
+- [x] **Backend Container Transformation**: Implemented syntactic sugar transformation in `internal/engine/engine.go`
+- [x] **Frontend Container Logic Removal**: Cleaned up `lib/src/core/insertr.js` - frontend finds enhanced elements only
+- [x] **Backend Viable Children**: Updated `internal/engine/utils.go` with comprehensive block/inline logic
+- [x] **Recursive Traversal**: Deep nesting support with proper boundary respect implemented
+- [x] **CLASSES.md Compliance**: Container expansion now follows specification exactly
+
+#### **Complex Element Handling** (Deferred)
+- [ ] **Table Editing**: Complex hierarchy needs separate planning for `<table>`, `<tr>`, `<td>` elements
+  - Tables have nested semantic structure that doesn't fit simple block/inline model
+  - Need to determine: Should individual cells be editable? Entire table? Row-level?
+  - Consider: Table headers, captions, complex layouts, accessibility concerns
+
+- [ ] **Form Element Editing**: Interactive form controls need specialized editors
+  - `<input>` fields: Different types need different editing interfaces (text, email, etc.)
+  - `<textarea>`: Should get rich text editing or preserve plain text?
+  - `<select>` options: Need dynamic option management interface
+  - `<form>` containers: Validation rules, action URLs, method selection
+  - Consider: Form submission handling, validation, accessibility
+
+- [ ] **Self-Closing Element Management**: Media and input elements
+  - `<img>`: Alt text, src, responsive image sets, lazy loading
+  - `<video>/<audio>`: Multiple sources, controls, accessibility features
+  - `<input>`: Type-specific validation, placeholder text, required fields
+
+### **🟢 Phase 4: Advanced CMS Features** (Low Priority)
 
 #### **Content Management Enhancements**
 - [ ] **Media Management**: Image upload, asset management, optimization