Add V162 payment-option linkage, slug transliteration, and sub-permission tab fixes

[mdon]

Merge order

This wave is three PRs across three repos, and they are not
independent:

#	PR	Why it must come first
1	phoenix_kit#682	V162 adds payment_option_uuid to phoenix_kit_orders; Utils.Slug gains the :transliterate option both modules call.
2	phoenix_kit_billing#15	Owns the Order schema — it casts the column V162 creates.
3	phoenix_kit_ecommerce#13	Checkout writes the payment-option link through billing's changeset.

Renumbered 2026-08-05: upstream merged its own V161
(case-insensitive username via citext) first, so this migration is now
V162. Its down/1 rolls the marker back to '161', not '160'.

Core must be RELEASED, not merely merged, before the module pins can
move — each module's pk_dep(:phoenix_kit, "~> …") floor should be raised
to that release as part of cutting it.

Nothing breaks if they land out of order, by design:

• Ecommerce checks the migrated version at runtime before writing the
  payment-option link, so on a host below V162 the order simply records no
  link rather than crashing on a missing column.
• Slug.slugify/2 ignores an option it does not know, so against an older
  core the Cyrillic slug fix silently no-ops and behaves exactly as it does
  today. The tests that assert it are gated on the capability and start
  running by themselves once the core release lands.

So an out-of-order merge costs the new features, not correctness.

---

Summary

Adds a nullable payment_option_uuid FK (plus its index) to
phoenix_kit_orders, pointing at phoenix_kit_payment_options.

An order records HOW it is to be paid via payment_method — a small
closed vocabulary (bank, stripe, paypal, razorpay). What the
customer actually chose at checkout is a payment-option ROW: an
operator-configured method with its own name, instructions, provider and
billing-profile requirement. The two are not the same thing. Several
options can share one payment_method ("Bank transfer (EU)" and "Bank
transfer (UK)" are both bank), and an option can be renamed or
deactivated after the order is placed.

Without a link the choice was discarded at conversion: nothing on the
order said which option the customer picked, so an operator processing a
bank transfer could not tell which instructions the customer had been
shown, and payment reconciliation had to guess.

Why ON DELETE SET NULL

Deactivating and deleting a payment option is an ordinary operator action.
It must not be blocked by historical orders, and it must not destroy them.
The order keeps payment_method and its metadata snapshot regardless, so
a deleted option degrades to "we know it was a bank transfer" rather than
to nothing.

Verification

add_if_not_exists / create_if_not_exists and matching down/1, so the
migration is re-runnable and reversible. The table comment moves to '161'
on up and back to '160' on down, per the marker convention.

---

Also in this PR

Three core changes the ecommerce wave surfaced. Each is independent of the
migration and of each other.

Utils.Slug gains opt-in transliteration

A Cyrillic title slugified to an empty string — every character fell
outside [a-z0-9] and was stripped. Callers read empty as "no slug yet",
so a Ukrainian shop's CSV catalogue could not be matched on re-import and
inserted the whole feed again on every run. The mapping covers Russian and
Ukrainian and also strips Latin diacritics.

It is opt-in: existing callers keep today's ASCII-only behavior, and a
consumer passing the new option against an older phoenix_kit gets today's
result rather than an error. phoenix_kit_ecommerce relies on that — its
Cyrillic tests are gated on the capability and start running once this
ships.

A tab gated on a sub-permission registers correctly

A module tab may be gated on a sub-permission ("shop.manage_settings").
Registration pushed that through register_custom_key/2, which rejects a
dotted key — and the raise aborted the rest of the callback, so the
view → permission mapping the admin gate reads was never cached. The module
silently fell back to the coarser base key for core's gate (its own mount
checks still held), and every boot logged a failure for a key that was
declared correctly. Sub-permissions are already declared through
permission_metadata/0, so registration now skips them.

The automatic view gate requires the base of a dotted key

Caching the dotted key means the admin mount gate now resolves one, and it
was calling has_module_access?/2 — direct membership only, which by
contract leaves the base check to its caller. A scope holding an orphaned
"shop.manage_settings" without "shop" would have passed a gate the
sidebar, can?/2 and every module's own check all refuse.

feature_enabled?/1 resolves a dotted key through its parent and
all_module_keys/0 includes sub-keys, so Owner and a properly-granted
Admin both still pass — pinned by tests.

[mdon]

⚠️Migration number collision with #681.

#681 (opened ~5h earlier) also adds lib/phoenix_kit/migrations/postgres/v161.ex, for the citext username change. Both PRs claim V161 and both bump @current_version to 161, so whichever merges second needs renumbering to V162 — the file, the module name, the @current_version bump, the index entry in postgres.ex, and the table-comment marker in both up/1 and down/1.

I'd suggest merging #681 first (it is older and self-contained) and renumbering this one to V162; happy to do that rebase on request. Flagging rather than renumbering pre-emptively, since the order is yours to choose.

The two migrations touch different tables (phoenix_kit_users vs phoenix_kit_orders), so there is no conflict beyond the version number itself.

[ddon]

@mdon please resolve the conflict