Defer splitting GStraccini-bot’s interface tables out of the webhooks database

gstraccini-bot-service’s production code currently connects directly to the webhooks database and reads/writes its user-interface tables (notifications, pending_actions, user_installations, recent_activities, user_profiles, user_preferences, user_settings, user_integrations, user_credentials, user_totp, user_recovery_codes, user_password_resets — created here by Sql/0017–0025). gstraccini-bot-service already carries its own Sql/ migration history for these same tables, but that pipeline is deliberately not run against anything yet — it exists for the day the bot gets its own dedicated database.

We’re not splitting the schema now. webhooks is being retired within the next few months as GStraccini-bot’s features move fully into its own repo, and a live database split for a repo that’s already being sunset isn’t worth the migration risk. Until that cutover, webhooks’ Sql/ migrations remain the single source of truth for these tables.

Consequences

• Running gstraccini-bot-service’s dormant Sql/ migrations against the shared webhooks database before the cutover is complete would be destructive — its own 0008.recreate_notifications_and_pending_actions_tables.sql starts with DROP TABLE IF EXISTS, which would drop the live tables both services currently depend on.
• webhooks’ Sql/ migrations must keep treating these tables as live and in-use, not legacy — despite no PHP code under webhooks/Src reading or writing them, they are not safe to drop or alter unilaterally from this repo.
• When the cutover happens, it should run gstraccini-bot-service’s migrations against a new, separate database, then repoint gstraccini-bot-service’s connection secrets — not attempt an in-place schema split of the shared database.