Fix a critical bug: refactors model bindings to use config-based resolution

[AHMED-GAMAL-AG]

Description

Replaces direct model class dependencies with configurable model bindings to improve flexibility and maintainability. Now, model classes can be swapped out via configuration without modifying the core code.

---

Key Changes

• Replaces hardcoded model class references with config lookups
• Adds validation for model instance types
• Updates tests to use configured model classes
• Maintains backward compatibility with existing model structure

This improves package extensibility by allowing users to override default models through configuration rather than inheritance.

---

Use Case & Background

In certain scenarios—such as in a multi-tenant application—I needed to override the model’s default connection. Despite having already overridden the default models in the soulbscription.php config, unexpected exceptions occurred when some parts of the code still referenced the original model classes directly rather than the user-configured ones.

For example, using $subscriber->subscription->plan or other relationships worked fine because those models were loaded correctly from the custom config. However, methods like $subscriber->getFeaturesAttribute() triggered exceptions by referencing LucasDotVin\Soulbscription\Models\Feature instead of the custom App\Models\Feature. This caused queries against the wrong database connection, resulting in "table not found" errors in my tenant database.

By replacing all direct references with configurable bindings, this PR ensures that every part of the package consistently respects the models defined in the soulbscription.php config, eliminating the need to modify core code for custom requirements.

---

Screenshots & Illustrations

Example of Configured Model Override

Override the Default Connection

Showcase Example

Using $subscriber->subscription->plan or any relation works correctly, because the relation loads the models from the custom soulbscription.php config:

However, calling $subscriber->getFeaturesAttribute() triggers an exception that the features table is not found in the tenant database (which is correct, as it resides in the main app database). The root issue is that getFeaturesAttribute() calls loadTicketFeatures(), which references LucasDotVin\Soulbscription\Models\Feature instead of the custom App\Models\Feature.

Consequently, these errors appear in any method that doesn’t pull the models from the soulbscription.php config.

---

Conclusion

This PR ensures that all references to model classes within the package are resolved using the configurable bindings defined by the user. It significantly enhances maintainability and extensibility, allowing developers to override database connections or other model properties in a single location without modifying or forking the package’s internal code.

Thank you for reviewing!

[AHMED-GAMAL-AG]

Hi @lucasdotvin, please look at the pull request when you can, as it is critical. Thank you!

[lucasdotvin]

Hello @AHMED-GAMAL-AG! Thanks for opening this PR! I'm taking a look right now! (Sorry for the delay. 😅)

[AHMED-GAMAL-AG]

Hey @lucasdotvin, this review is taking like forever, isn't it 😄