fix(core): queue-safe catalog invalidation events (#2562)

[wakqasahmed]

Closes #2562

Problem

ProductInvalidated, CollectionInvalidated, BrandInvalidated, and ProductOptionInvalidated use Illuminate\Queue\SerializesModels on their model property. That trait's __unserialize restores the model by re-querying the database with firstOrFail(). For a Deleted invalidation, the row is already gone by the time a queued listener processes the job, so deserialization throws ModelNotFoundException before the listener can read morphType(), cacheKey(), cacheTags(), or reason() — the scalar identity the contract promises is captured at record time specifically so it survives a deleted row.

Fix

Added Lunar\Core\Concerns\SerializesInvalidatedModel, a queue-safe drop-in for SerializesModels on these four events. Instead of a ModelIdentifier that gets re-queried on unserialize, it captures the model's raw attributes at serialize time and rehydrates an in-memory instance via newFromBuilder() on unserialize — no query, so it can't fail even when the row no longer exists. cacheModel() still returns a real, fully-attributed Model instance; the public contract (CacheInvalidationEvent) is unchanged.

This is narrower than the additive scalar-only event / DTO the issue floated as an option: no new public surface, no change to the documented queued contract, and the model-bearing events become safe to queue as-is.

Test plan

• Added tests/core/Feature/CacheInvalidationTest.php coverage that constructs each of the four invalidation events, hard-deletes the underlying row, round-trips the event through PHP's real serialize()/unserialize() (the same mechanism a queued job uses), and asserts the restored event's scalar identity (cacheKey(), cacheTags(), morphType(), reason()) and cacheModel() are readable without hitting the database.
• Ran the full tests/core/Feature/CacheInvalidationTest.php suite (24 tests, 41 assertions) — all green, including the pre-existing coverage.

Tests:    24 passed (41 assertions)
Duration: 260.88s