Add meta.find_schema_problems(); every install runs 00-10; drop migrations

09_schema_check.sql adds meta.find_schema_problems(), a read-only check
any client (Python, C++, psql) can call:

    SELECT * FROM meta.find_schema_problems();   -- zero rows = usable

One row per problem (object, problem): missing schemas, extension,
sequences, tables, columns, wrong column type or NOT NULL, missing
constraints, indexes, views, stored-function bodies that differ from the
DDL (whitespace-insensitive md5 fingerprint), a missing/disabled/
misdirected event trigger, short reference data, no version row. It
mirrors 00-08 and must change in the same commit as they do; the
release test (a fresh install returns zero rows) enforces that.

10_schema_version.sql records VERSION in meta.schema_version. Before,
only the Python client wrote that row, so databases provisioned by
run_setup.py recorded no version at all.

run_setup.py now runs 00-10. It skipped 08_script_log.sql, so its
databases lacked a table the Python client uses; every fresh install is
now identical regardless of provisioner.

sql/migrate/ is removed: databases are re-provisioned, not migrated.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

sql/10_schema_version.sql

@@ -0,0 +1,8 @@
+-- ============================================================================
+-- Schema version row -- runs last, so a database that has it is complete.
+-- ============================================================================
+-- Keep this string equal to ../VERSION. Clients compare it with the version
+-- they were built for (Python: DB_SCHEMA_VERSION in tsapi_pgdb/_version.py).
+
+INSERT INTO meta.schema_version (version, description)
+VALUES ('1.0.0', 'Initial schema');