Add ensure_current/2 helper + V110 language column on doc templates

[mdon]

Summary

Two changes bundled here:

1. PhoenixKit.Migration.ensure_current/2 — re-runnable analog of
   mix ecto.migrate for test helpers and any boot path that runs against
   a long-lived DB. Fixes a latent staleness bug where the documented
   canonical pattern stops applying newly-shipped Vxxx migrations after
   the first boot.

2. V110 — language column on phoenix_kit_doc_templates — adds a
   nullable VARCHAR(10) column so Document Creator templates can be
   tagged with a single locale (full code, e.g. en-US, et-EE). Parent
   apps will read this back via the public listing API to fill template
   variables in the matching language regardless of the admin's UI
   locale. Resolves the design ask in
   BeamLabEU/phoenix_kit_document_creator#13.

---

(1) ensure_current/2 — the bug

The pattern shipped in dev_docs/migration_cleanup.md and copied into
every consuming module's test_helper.exs:

Ecto.Migrator.run(repo, [{0, PhoenixKit.Migration}], :up, all: true)

is idempotent at the outer layer — Ecto.Migrator records "version 0
applied" in schema_migrations after the first call and filters
{0, PhoenixKit.Migration} out of pending on every subsequent boot.
PhoenixKit.Migration.up/1 is never re-invoked, so newly-shipped Vxxx
migrations never apply even though PhoenixKit's own marker (the comment
on the phoenix_kit table) is itself idempotent.

Symptom: column ... does not exist after mix deps.update phoenix_kit
pulls in new migrations but the test DB stays at the old marker. The
two layers of idempotency cancel each other out.

Verified empirically — core's own phoenix_kit_test was at marker 107
even though Hex 1.7.103 ships V108 + V109. The original wrapper at
test/support/postgres/migrations/20260316000000_add_phoenix_kit.exs
hadn't re-run since first DB creation.

The fix

ensure_current/2 passes a fresh wall-clock version
(:os.system_time(:microsecond)) to Ecto.Migrator.up/4 on every
call. Ecto sees a "new" migration each time and invokes the inner
runner; PhoenixKit's marker short-circuits internally if there's
nothing new to apply. Microsecond precision keeps the collision /
clock-skew window vanishingly small.

# In test/test_helper.exs
PhoenixKit.Migration.ensure_current(MyApp.Test.Repo, log: false)

Forwards :prefix from the Ecto.Migration runner context via the
internal Runner module's runner_opts/0 so callers passing
prefix: "auth" aren't silently routed to "public".

The schema_migrations table accumulates one row per call (with a
microsecond-precision timestamp as the version) — cosmetic noise
acceptable for the test-DB use case.

---

(2) V110 — language on document templates

Document Creator templates are inherently single-language (one Google
Doc = one language; translations live in separate templates). Today
parent apps fall back to either a global hardcoded value or the admin's
session locale when filling template variables — both wrong, since an
Estonian-language template should always be filled with Estonian
values regardless of which UI locale the admin happens to use.

V110 adds:

ALTER TABLE phoenix_kit_doc_templates ADD COLUMN language VARCHAR(10);

• Nullable, so existing rows survive without a backfill. The form
  in phoenix_kit_document_creator will pre-select the project's
  primary language (sourced from PhoenixKit.Modules.Languages) when
  creating new templates and let users change it from the admin UI.
• Full locale codes (en-US, et-EE, ja) — matches what
  Languages.get_enabled_languages/0 returns, lossless. Consumers
  that want bare base codes can derive them via
  DialectMapper.dialect_to_base/1.
• Templates only. Documents inherit language from
  template_uuid → templates.language — they don't get their own
  column.

Schema/API changes in phoenix_kit_document_creator will land
separately on that repo.

---

What's NOT changed

• Production migrations via mix ecto.migrate /
  mix phoenix_kit.update continue to work the same way; V110 is just
  the next versioned migration in line.
• Existing consumer modules' test_helper.exs files are untouched.
  They can migrate to ensure_current/2 at their own pace; the old
  pattern still works (just with the latent staleness bug). Workspace
  dev_docs/migration_cleanup.md documents the cutover.

Test plan

• mix format --check-formatted clean
• mix credo --strict — 7313 mods, no issues
• mix dialyzer — 0 errors
• mix test — 1049 tests; 3 pre-existing V107 failures verified on stock dev (stale-DB drift unrelated to this PR)
• Empirical: marker advanced from 107 → 109 on the first test run after the change, confirming new migrations actually apply
• V110 applied via mix phoenix_kit.update against phoenix_kit_parent_dev; column exists, nullable, VARCHAR(10), marker advanced to 110
• Browser-verified end-to-end through phoenix_kit_parent admin pages (catalogue list, smart catalogue detail, item edit form, search, paged list with 311 items) — 0 console errors
• Phase 2 quality review applied — 4 fixes (CRITICAL prefix-loss bug + HIGH clock-skew hardening + spec/test cleanup)

Followup

dev_docs/migration_cleanup.md and dev_docs/quality_sweep.md updates
land alongside (in the workspace, not this repo). Consumer modules
adopting ensure_current/2 come as separate PRs — first is
phoenix_kit_catalogue (companion to this PR, paired merge).