refactor: Remove deprecated database migration system (#142)

* refactor: Remove deprecated database migration system

The migration system has been deprecated in favor of a flattened v1.0
schema. All historical migrations have been incorporated into the
Database._create_schema() method.

Changes:
- Remove _run_migrations() method from database.py
- Remove run_migrations parameter from Database.initialize()
- Delete entire migrations/ directory and infrastructure
- Delete migration-specific test files (6 files)
- Remove run_migrations parameter usage from all test files
- Delete migration verification script
- Update documentation to reflect flattened schema approach
- Update deployment script to reference schema initialization

All tests passing (34/34 in test suite sample).

Rationale:
The flattened schema approach is simpler for pre-production development
and eliminates the complexity of managing migrations. The complete
schema is now defined in one place (_create_schema) making it easier
to understand and maintain.

* chore(docs) remove old and outdated analysis documentation

* fix: Remove stale migration references from code and tests

Address code review feedback:

1. database.py:
   - Updated error messages to remove references to non-existent migration 011
   - Changed "after migration 011" to "enforced by schema"
   - Updated error messages to clarify schema-level enforcement

2. test_database_typed_returns.py:
   - Removed misleading `db_no_migrations` fixture
   - Replaced complex NULL validation tests with simpler schema constraint tests
   - Renamed TestNullCreatedAtValidation to TestCreatedAtSchemaConstraint
   - Tests now verify that the schema prevents NULL values (instead of trying to insert them)
   - Removed all references to migration 011

All 17 tests passing.

Author: frankbria

CLAUDE.md

@@ -38,7 +38,7 @@ Quick reference:
 └── docs/             # Additional documentation
 ```
 
-NOTE: This is a pre-production application, so there is no need for database migration scripting or backward compatibility. Keep the schema flat as much as possible.
+NOTE: This is a pre-production application with a flattened v1.0 database schema. The schema uses direct table creation with no migration system.
 
 ## Commands
 ```bash
@@ -93,7 +93,7 @@ python scripts/quality-ratchet.py show
   * **Before**: One project per agent (broken architecture)
   * **After**: Multiple agents (orchestrator, backend, frontend, test, review) collaborate on same project
   * **Tests**: 59/59 passing (100%) - Full multi-agent test coverage
-  * Phase 2: Foundational layer (Pydantic models, migrations, database methods, TokenCounter)
+  * Phase 2: Foundational layer (Pydantic models, database methods, TokenCounter)
   * Phase 3: Context item storage (save/load/get context with persistence)
   * Phase 4: Importance scoring with hybrid exponential decay algorithm (T027-T036)
   * Phase 5: Automatic tier assignment HOT/WARM/COLD (T037-T043, T046)

CODEFRAME_ISSUES_ANALYSIS.md

@@ -137,12 +137,6 @@ CodeFRAME is an ambitious AI-powered software development system with a comprehe
 - **Impact**: Users cannot understand how to use the system
 - **Evidence**: Missing OpenAPI specs and docstrings
 
-#### Missing Migration Documentation
-- **Issue**: Database migration system is documented but incomplete
-- **Location**: `codeframe/persistence/migrations/README.md`
-- **Impact**: Database schema changes are difficult to manage
-- **Evidence**: Template migration files with XXX placeholders
-
 ## Specific Functionality Gaps
 
 ### Agent System Issues