Remove orphaned duplicate apikey migration

[nearbycoder]

Summary

Deletes drizzle/0002_wonderful_thunderbolt.sql, which is an orphaned migration file that:

1. Is byte-for-byte equivalent to drizzle/0001_api_key_support.sql (both CREATE TABLE "apikey" with the same columns, FK, and indexes).
2. Is not referenced in drizzle/meta/_journal.json — the journal already lists 0001_api_key_support, 0002_share_link_expiry, and 0003_long_jimmy_woo, but never the wonderful_thunderbolt tag, so the runtime migrator silently skips it today.
3. Shares the 0002_ numeric prefix with 0002_share_link_expiry.sql, which is invalid for drizzle. If anyone ever regenerated the journal to include it, the migrator would either fail with a duplicate-prefix conflict or attempt to re-create the existing apikey table and crash on every fresh deploy.

Removing it brings the filesystem back in sync with the journal and eliminates the latent footgun.

Verification

• drizzle/meta/_journal.json does not reference the wonderful_thunderbolt tag, so no runtime behavior changes.
• 0001_api_key_support.sql continues to create the apikey table identically.
• No code in src/ references the file.

Follow-up (not in this PR)

There are pre-existing inconsistencies in drizzle/meta/ worth a separate look:

• 0001_snapshot.json is missing entirely.
• 0002_snapshot.json and 0003_snapshot.json both have prevId pointing back to 0000_snapshot.json's id, instead of forming a proper chain.

These don't affect drizzle-kit migrate at runtime, but the next drizzle-kit generate will likely produce conflicts. Recommend regenerating snapshots against a fresh baseline in a follow-up PR.

---

Pull Request opened by Augment Code | View session