Refactoring Table Removal Order in Migrations

[herculanosilva]

Upon reviewing the migration logic, it became apparent that we were initially attempting to drop the 'team_user' table, which has a foreign key referencing the 'teams' table. This order was leading to conflicts during the refresh execution.

In the proposed solution, we reversed the removal order, deleting the 'team_user' table first before 'teams'. This ensures there are no foreign key violations during the database update process.

This change aims to enhance the robustness of the migration process by providing a more logical and secure order for table removal, minimizing potential issues during database refresh.

public function down(): void
{
    Schema::dropIfExists('team_user');
    Schema::dropIfExists('team');
}