feat!: migrations move under il migration; Python script becomes inputlayer-migrate - #101

…mes inputlayer-migrate

il is the single product CLI and migrations are a noun group under it:
il migration generate / apply / revert / status. The delegation layer in
the il binary translates these to the Python tool's subcommands, so
Django-flavored names (makemigrations) never surface in the product CLI
and 'il migrate migrate' never exists.

The SDK's console script is renamed from 'il' to 'inputlayer-migrate'
(matching its existing argparse prog) so the name 'il' belongs to the
product CLI alone. Docs updated to the new vocabulary.

Breaking for scripts invoking the old Python 'il' directly: use
'il migration <verb>' (or 'inputlayer-migrate <subcommand>' where only
the SDK is installed).

Found by running the full lifecycle (generate/apply/status/revert)
end to end via il migration against a live server. Two bugs, both
invisible to the mocked unit tests:

1. The recorder relation was named __inputlayer_migrations__. The
   engine rejects that name in schema declarations (must start with a
   lowercase letter) but silently auto-creates it untyped on insert,
   and queries against it fail - so applied-state was written into a
   relation that could never be read. Renamed to inputlayer_migrations.
   (Engine-side inconsistency filed separately: inserts bypass the
   relation-name validation that schema declarations enforce.)

2. get_applied() used '?Name, At <- rel(Name, At)', which the engine
   rejects ('Query cannot contain a rule definition'). Every status
   read returned [], so showmigrations always showed unapplied, revert
   never found anything, and apply re-applied migrations every run.
   Switched to the plain query form and deduplicated.

Also: --migrations-dir is now accepted after the subcommand on every
subcommand (argparse.SUPPRESS so the global default survives), since
delegating callers always place flags after the subcommand.

Verified live: generate -> apply -> status [X] -> re-apply no-op ->
second migration -> revert to 0001 -> status shows [X]/[ ]. Parser
position tests added; full SDK suite 960 passed.

Migration artifacts were Python source (operations rendered as code,
loaded via importlib) - unusable by any other SDK language, and even
listing history required a Python runtime. Migrations are now data:

- writer emits NNNN_name.json: {format, dependencies, operations, state}
  using the to_dict/from_dict serialization the operation classes
  already had. No code, no imports, nothing language-specific.
- loader reads both formats: JSON (current) and legacy .py (back-compat,
  read-only). JSON state normalizes column pairs back to tuples so the
  autodetector sees no phantom changes.
- test_writer rewritten for the JSON document (structure, operation
  roundtrip incl. forward/backward command equality, no-code guarantee);
  legacy .py loading stays covered in test_loader. Suite: 956 passed.
- migrations guide: anatomy section now shows the JSON document.

This is step 1-2 of #104: the on-disk format is now consumable by a
future JS frontend and by il natively (apply/revert/status without any
SDK installed). Verified live: generate -> apply -> status -> revert
against a running engine with JSON files.

Pre-1.0 decision: no legacy formats. The importlib-based .py loader,
the Migration base class it existed for (and its package exports), and
the dual-format handling are gone. Stray .py files from older SDKs are
inert - ignored by discovery, never imported, never double-applied.
Duplicate-number detection remains for renumber collisions.

test_loader rewritten around JSON; safety tests updated (stray .py twin
is ignored); docs and GUI bundle updated. Suite: 969 passed.