Guard catalog pricing rule lookup during migrations

[boboldehampsink]

Summary

• Return false from CatalogPricingRules::hasCatalogPricingRules() when the catalog pricing rules table has not been created yet.
• Prevent product/purchasable queries from touching commerce_catalogpricingrules while Craft/Commerce migrations are still being applied.

Context

During a Craft 5 / Commerce 5 upgrade, a Craft CMS migration can save single entries and serialize product relation fields before Commerce has applied m221026_105212_add_catalog_pricing_table. That path calls ProductQuery::beforePrepare(), which calls hasCatalogPricingRules(), and currently attempts exists() against commerce_catalogpricingrules even when the table does not exist yet.

Treating the missing table as “no catalog pricing rules yet” lets migrations continue until Commerce creates the table normally.

[boboldehampsink]

Added a second guard for the same migration-order path.

After the catalog pricing rules table guard, the upgrade continued until product relation serialization hit ProductQuery joins against commerce_site_stores before m230110_052712_site_stores had created it. The latest commit now gates store-dependent joins/selects in ProductQuery and PurchasableQuery, and also avoids the later inventory-item join until commerce_inventoryitems exists.

[boboldehampsink]

Added another migration-order guard.

The next failure was from ProductQuery selecting Commerce 5 purchasable detail columns (weight, length, width, height) before m221025_083940_add_purchasables_stores_table had moved those columns from variants onto commerce_purchasables. The latest commit selects NULL for those fields until the columns exist, and aborts only when the query is explicitly filtering by unavailable purchasable detail columns.

[boboldehampsink]

Added a migration data-repair fix for m240219_194855_donation_multi_store.

The migration assumes every commerce_donations row has a matching commerce_purchasables row before inserting into commerce_purchasables_stores. On the upgrade database, a donation row existed without the base purchasable row, causing a foreign key violation. The latest commit backfills the missing purchasable record from the donation row before creating store-specific purchasable rows.