Engine: inserts bypass relation-name validation, creating unreadable ghost relations #106

Summary

Schema declarations and inserts enforce relation naming inconsistently, and the result is a relation that can be written but never read.

Repro (verified on a live server, 2026-08-19)

.kg create underscore_repro
.kg use underscore_repro
+__dunder(name: string)     -- rejected: 'Relation name __dunder must start with lowercase letter'
+__dunder[("a",)]           -- ACCEPTED: 'Inserted 1 fact(s)' (auto-created, untyped: col0 any)
?__dunder(N)                -- fails: 'Cannot insert variable N - use constants only'

The insert path auto-creates the relation without running the name validation that the schema-declaration path enforces, and the query parser then cannot address the relation at all (the error message is also misleading - a query is reported as an insert problem).

Impact

This made the Python SDK's migration recorder silently broken in production use: it recorded applied migrations into inputlayer_migrations (write succeeded), but status/revert could never read them back, so showmigrations always showed unapplied and apply re-ran migrations every time. Fixed on the SDK side by renaming the relation (PR #101), but the engine should refuse the insert exactly like it refuses the declaration.

Suggested fix

Run the same relation-name validation on the insert auto-create path as on schema declarations, and fix the query error message for unaddressable relation names.

Related: the parse error for the invalid schema declaration is returned as an informational message rather than an error frame, so SDK clients cannot detect it programmatically - worth folding into the same pass.