feat(store): versioned migrations for handler-owned tables (#33)

[kunal171]

Closes #33.

Problem

The framework versions its own schema (subdex_block via MIGRATOR, tracked in _sqlx_migrations), but handler entity tables were created ad-hoc with CREATE TABLE IF NOT EXISTS in init(). That pattern cannot express an evolution — adding a column or an index to an already-deployed database — so a fresh DB and an upgraded one could silently diverge, and users were on their own.

Fix

PgStore::run_handler_migrations(&Migrator, name) — a handler embeds its own versioned set with sqlx::migrate!("./migrations/<name>") and runs it from init:

static MIGRATOR: subdex_store::Migrator = sqlx::migrate!("./migrations/assets");

async fn init(&self, store: &PgStore) -> Result<()> {
    store.run_handler_migrations(&MIGRATOR, self.name()).await
}

• Applied once, in order, and recorded.
• Tracked in a per-handler table (_sqlx_migrations_<name>, via sqlx's dangerous_set_table_name) — isolated from the framework's _sqlx_migrations, so handlers never collide with each other or with the framework.
• Idempotent: re-running init applies nothing new; a fresh DB and an already-migrated one converge.
• handler_migrations_table(name) sanitizes to a safe unquoted identifier ([a-z0-9_], fallback handler) — 3 unit tests.
• sqlx's Migrator is re-exported from subdex-store so handlers don't depend on sqlx directly.

Implementation note: Migrator isn't Clone and the caller's is a &'static, so we build an owned copy (all fields are Cow/bool) and point that at the handler's table — the caller's stays untouched.

Dogfood

The multi-pallet AssetsHandler now owns migrations/assets/ (0001 create table, 0002 add an index — exactly the evolution the old pattern couldn't do) and applies them via the helper. BalancesHandler keeps the ad-hoc CREATE TABLE IF NOT EXISTS for contrast.

Acceptance criteria — verified live against real Postgres (9/9 pass)

• A handler can ship an ordered set of migrations that apply once and are recorded — handler_migrations_apply_once_in_order_and_are_idempotent asserts the table exists (0001), the v2 column exists (0002), and 2 rows are recorded in _sqlx_migrations_widgets.
• Re-running init is idempotent; partially-migrated DBs converge — the re-run applies nothing new (still 2).
• Documented with an example — architecture gains a "Schema ownership: who migrates what" section; the multi-pallet README documents the pattern.

Also asserted: the framework's _sqlx_migrations is untouched (still 1 row) by handler migrations, and two handlers get separate tracking tables.

Verification

fmt / clippy -D warnings / test / doc all clean (default + --all-features); PG integration tests run live (9/9).