Future: migrate persistence to Drizzle ORM + introduce internal event bus for logging

Tracking issue for a long-term architecture improvement, deliberately deferred from the initial Postgres/member-storage work (2026-08 design).

## Context
The initial Meetup ID storage feature uses a minimal setup: the `pg` driver, a single `members` table created idempotently at startup, one repository module, and direct calls to a `discordLogger` helper at each log-worthy call site. This was the right size for one table and ~6 call sites.

## When to revisit
Consider this migration when any of the following happens:
- A second or third table is added (real migration tooling starts paying for itself vs. hand-rolled `CREATE TABLE IF NOT EXISTS` / `ALTER TABLE` guards).
- Schema changes need to be reviewed/versioned rather than applied on boot.
- The number of Discord-logged event types grows enough that sprinkling `logActivity()`/`logAlert()` calls becomes repetitive or inconsistent.

## Proposed shape
- **Drizzle ORM + drizzle-kit**: typed schema definitions, generated SQL migrations checked into the repo, run on deploy (Heroku release phase) instead of at boot.
- **Internal event bus**: bot code emits domain events (`member.onboarded`, `member.duplicate_blocked`, `event.announced`, `command.failed`, ...); subscribers handle Discord channel logging, DB writes, and any future sinks independently. Decouples "what happened" from "where it goes".

## Non-goals for now
No behavior change intended when this lands — pure internals refactor.

No files, tests, or entry points are named. Revisit the issue only after a second or third table, versioned schema changes, or substantially more Discord-logged event types make the migration worthwhile. Define the migration and event-bus design before implementation, while preserving current behavior.

Written by the indexing model from the issue text.