Replace dev/schema.sql with Laravel migrations in the backend

Baseline migration reproduces the production dump byte-for-byte (verified via
mariadb-dump diff); creates are hasTable-guarded so prod only records it.
Drop stock Laravel migrations that contradict prod and Sanctum's bundled one.

README.md

@@ -19,10 +19,14 @@ nix run                # installs vendors on first run, starts MariaDB, serves b
 
 ### Database
 
-`dev/schema.sql` is the schema (10 tables, no `category` table — `category_id` 1/2 is hardcoded).
-It is derived from the production dump and applied automatically on every `db start`
-(idempotent), so a fresh checkout serves empty pages with no 500s. There are no Laravel
-migrations for these tables; edit `dev/schema.sql` when prod changes.
+The schema is owned by the CMS: `think-backend.greaterchiangmai.com/database/migrations/`
+(10 tables; no `category` table — `category_id` 1/2 is hardcoded). `dev db start` runs
+`artisan migrate` there on every start, so a fresh checkout serves empty pages with no 500s.
+
+`2025_11_03_000000_create_content_tables` is a baseline that reproduces the production
+tables byte-for-byte (verified by diffing `mariadb-dump --no-data` against the prod export);
+its creates are guarded with `Schema::hasTable`, so running `migrate` on production only
+records it. Add new migrations in the backend for any schema change; the site app has none.
 
 To work with real content, load a production dump (drops and recreates the local DB):