[FEATURE]: record the migration name in `__drizzle_migrations`

### Feature hasn't been suggested before.

- [x] I have verified this feature I'm about to request hasn't been suggested before.

### Describe the enhancement you want to request

`__drizzle_migrations` stores only `hash` and `created_at`:

```sql
CREATE TABLE IF NOT EXISTS "drizzle"."__drizzle_migrations" (
id SERIAL PRIMARY KEY,
hash text NOT NULL,
created_at bigint
)
```

So the table cannot answer "which migrations are applied on this database" on its own. Doing it today means checking out the matching commit, re-hashing every `.sql` in the migrations folder, and joining on `hash`:

```sql
WITH journal(tag, when_ms, hash) AS (VALUES
('0056_member_threshold_column', 1787318876659, 'bcf3f6f2…'),
...
)
SELECT j.tag, (m.hash IS NOT NULL) AS applied, m.created_at
FROM journal j
LEFT JOIN drizzle.__drizzle_migrations m ON m.hash = j.hash;
```

Both available join keys are fragile:

- **`hash`** stops matching if a migration file was edited after being applied.
- **`created_at`** stops matching if a row was inserted by hand, which is the documented recovery path for journal/table drift.

Neither is available at all without the repo in front of you, which is the wrong constraint when you are looking at a production database during an incident.

Flyway solves this by storing `version`, `description` and `script` in `flyway_schema_history`, so the table is self-describing.

**Proposal:** add a nullable `name` (or `tag`) `text` column and populate it from the journal entry on insert. Nullable keeps it additive - existing rows stay `NULL`, no backfill or rewrite of the migrations table is needed, and anything reading it can fall back to `hash` exactly as today.

Two things this would also improve:

- Diagnosing #5769: a silently skipped migration currently shows up as an absent hash, so identifying *which* one requires the same re-hashing exercise.
- Failure messages. When a migration fails mid-run, the name is the first thing anyone wants and it is the one thing not recorded anywhere.

I could not find an existing issue for this - searching the repo for `flyway schema_history` returns nothing, and the adjacent requests (#2229, #3410, #4422) are all about log output rather than what the table persists.

Start by finding the migration-table creation and journal insert paths for each supported database dialect. Trace how journal entries supply the migration tag, then verify that new __drizzle_migrations rows record the name while preserving existing hash and created_at behavior and leaving existing rows compatible.

Written by the indexing model from the issue text.