Fix provider DB upgrades with existing tables

[anmolxlight]

This restores the provider-scoped DB manager compatibility handling that was split out from #66674.

When a provider's tables already exist but its Alembic version table has no revision, upgradedb() should stamp the provider base revision and then run migrations. Without this, provider upgrades can treat the DB as empty and call create_db_from_orm(), skipping incremental migrations.

Changes:

• add Airflow < 3.3 compatibility helpers to Edge3 and FAB provider DB managers
• make FAB upgradedb() stamp existing provider tables before upgrading
• add regression coverage for existing-table/no-version upgrade paths

Tests:

• uv run ruff format providers/edge3/src/airflow/providers/edge3/models/db.py providers/edge3/tests/unit/edge3/models/test_db.py providers/fab/src/airflow/providers/fab/auth_manager/models/db.py providers/fab/tests/unit/fab/auth_manager/models/test_db.py
• uv run ruff check providers/edge3/src/airflow/providers/edge3/models/db.py providers/edge3/tests/unit/edge3/models/test_db.py providers/fab/src/airflow/providers/fab/auth_manager/models/db.py providers/fab/tests/unit/fab/auth_manager/models/test_db.py
• uv run --project providers/fab pytest providers/fab/tests/unit/fab/auth_manager/models/test_db.py -q
• uv run --project providers/edge3 pytest providers/edge3/tests/unit/edge3/models/test_db.py -q

[jscheffl]

Looks good! @vincbeck already approved other PR so I assume good to merge directly