fix(migrations): Prevent core/internal migrations from dropping external app tables

[Parth971]

Problem

When creating core or internal app migrations after external apps were attached to the project, Alembic's autogenerate would incorrectly attempt to drop external app tables. This happened because:

1. Core/internal migrations only collect metadata from core models and internal apps
2. Alembic compares this target metadata against the entire database (which includes external app tables)
3. External app tables appear as "extra" tables that should be dropped

Example scenario:

• External app creates tables: eapp_eusers, alembic_version_eapp
• Core creates DefaultUsers model and generates migration
• Migration incorrectly includes: op.drop_table('eapp_eusers') and op.drop_table('alembic_version_eapp')

Solution

This PR fixes the issue by:

1. Loading app registry in core migration command to identify external apps
2. Collecting external app table names (both model tables and version tables) during autogenerate
3. Adding include_object callback in core migrations env.py to exclude external app tables from autogenerate comparison
4. Applying to both core and internal apps since they share the same migration directory (core/db/migrations/) and version table (alembic_version)

Changes

• fastappkit/cli/migrate.py: Load registry and pass to autogen for core migrations
• fastappkit/migrations/autogen.py: Collect external app tables and store in config attributes
• fastappkit/cli/templates/project/core/db/migrations/env.py.j2: Add include_object callback to filter external app tables

Testing

• ✅ Core migrations no longer drop external app tables
• ✅ Internal app migrations no longer drop external app tables
• ✅ External apps remain unaffected (isolated migration system)
• ✅ Works when external apps are attached before or after core migrations

Notes

• External apps are completely isolated and unaffected by this change
• The fix uses Alembic's built-in include_object callback mechanism
• Both core and internal apps need this fix since they share the same migration timeline