docs: Align documentation with true microservices architecture

Transform all documentation from modular monolith to true microservices
architecture where core services are independently deployable.

Key Changes:
- Core Kernel: Infrastructure only (no business logic)
- Core Services: Auth, Identity, Authz, Audit as separate microservices
  - Each service has own entry point (cmd/{service}/)
  - Each service has own gRPC server and database schema
  - Services register with Consul for service discovery
- API Gateway: Moved from Epic 8 to Epic 1 as core infrastructure
  - Single entry point for all external traffic
  - Handles routing, JWT validation, rate limiting, CORS
- Service Discovery: Consul as primary mechanism (ADR-0033)
- Database Pattern: Per-service connections with schema isolation

Documentation Updates:
- Updated all 9 architecture documents
- Updated 4 ADRs and created 2 new ADRs (API Gateway, Service Discovery)
- Rewrote Epic 1: Core Kernel & Infrastructure (infrastructure only)
- Rewrote Epic 2: Core Services (Auth, Identity, Authz, Audit as services)
- Updated Epic 3-8 stories for service architecture
- Updated plan.md, playbook.md, requirements.md, index.md
- Updated all epic READMEs and story files

New ADRs:
- ADR-0032: API Gateway Strategy
- ADR-0033: Service Discovery Implementation (Consul)

New Stories:
- Epic 1.7: Service Client Interfaces
- Epic 1.8: API Gateway Implementation

docs/content/stories/epic4/README.md

@@ -1,31 +1,39 @@
-# Epic 4: Sample Feature Module (Blog)
+# Epic 4: Sample Feature Service (Blog Service)
 
 ## Overview
-Create a complete sample module (Blog) to demonstrate the framework, showing how to add routes, permissions, database entities, and services. The Blog module is an independent service that uses service clients to communicate with core services. Provide reference implementation for future developers.
+Create a complete sample feature service (Blog Service) to demonstrate the framework. The Blog Service is an independent service with its own entry point (`cmd/blog-service/`), gRPC server, and database schema. It uses service clients to communicate with core services (Auth, Identity, Authz, Audit). This serves as a reference implementation for future developers creating feature services.
+
+**Key Principle:** Blog Service demonstrates how to create a feature service that integrates with the platform using service clients and Consul service discovery.
 
 ## Stories
 
-### 4.1 Complete Blog Module
-- [Story: 4.1 - Blog Module](./4.1-blog-module.md)
-- **Goal:** Create a complete sample blog module to demonstrate the framework.
-- **Deliverables:** Complete blog module with CRUD operations, permissions, database entities, services, API handlers, and integration tests
+### 4.1 Complete Blog Service
+- [Story: 4.1 - Blog Service](./4.1-blog-module.md)
+- **Goal:** Create a complete sample blog service to demonstrate the framework.
+- **Deliverables:** Complete blog service with entry point, gRPC server, database schema, CRUD operations, permissions, service client integration, and integration tests
 
 ## Deliverables Checklist
-- [ ] Blog module directory structure created
-- [ ] Module manifest defines permissions and routes
+- [ ] Blog service entry point (`cmd/blog-service/main.go`)
+- [ ] Blog service directory structure (`services/blog/`)
+- [ ] gRPC service definition (`api/proto/blog.proto`)
+- [ ] gRPC server implementation
+- [ ] Service manifest defines permissions
 - [ ] Blog post domain model defined
-- [ ] Ent schema for blog posts created
+- [ ] Ent schema for blog posts (blog schema)
 - [ ] Repository implements CRUD operations
 - [ ] Service layer implements business logic
-- [ ] API endpoints for blog posts working
-- [ ] Module integrated with core platform
+- [ ] Service uses service clients (Identity, Authz, Audit)
+- [ ] Service registers with Consul
 - [ ] Integration tests passing
 
 ## Acceptance Criteria
-- Blog module can be registered with core platform
-- Permissions are generated for blog module
+- Blog service is independently deployable
+- Service entry point exists at `cmd/blog-service/main.go`
+- Service registers with Consul on startup
+- gRPC server starts on configured port
 - CRUD operations work for blog posts
-- API endpoints require proper authentication
-- Module migrations run on startup
-- Blog posts are associated with users
-- Authorization enforced (users can only edit own posts)
+- Service uses IdentityServiceClient for user operations
+- Service uses AuthzServiceClient for authorization
+- Service uses AuditServiceClient for audit logging
+- Service has its own database schema (blog schema)
+- Service can be discovered by API Gateway via Consul