Database Migrations - Migrations are taking priority over content-type changes
<!--
Hello 👋 Thank you for submitting an issue.

Before you start, please make sure your issue is understandable and reproducible.
To make your issue readable make sure you use valid Markdown syntax.

https://guides.github.com/features/mastering-markdown/

Please ensure you have also read and understand the contributing guide.

https://github.com/strapi/strapi/blob/main/CONTRIBUTING.md#reporting-an-issue
-->

## Bug report

### Required System information

<!-- Please ensure you are using the Node LTS version (18, 20, or 22) -->
<!-- Strapi v3 is no longer supported, please update to Strapi v4 -->
<!-- If you are reporting a frontend bug please provide error logs after setting STRAPI_ENFORCE_SOURCEMAPS=true in your .env -->
<!-- This environment variable makes frontend errors easier to read and trace -->

- Node.js version: 20.14.0
- NPM version: 10.7.0
- Strapi version: 4.25.6
- Database: Postgres
- Operating system: OSX
- Is your project Javascript or Typescript: Typescript

<!-- Did you know you can run `yarn strapi report` or `npm run strapi report` to get this information easier? -->

### Describe the bug

In cases where we have changes to a content-type from admin panel and db migrations operating on the added/modified columns/fields , the migrations are run before content-type changes are reflected on the db expecting the columns to be there.

### Steps to reproduce the behavior

1. Go to Admin panel Content type builder
2. Add a field on an existing content type (let's call it 'status') and save
3. Generate a migration updating the status field of the content-type/model to 'created'
4. Commit all your changes and deploy the application or run the application on a different environment after pulling the changes.
5. The migration would fail expecting the status column to be there in the content-type. 

### Expected behavior

Really not sure about a right behavior here as there could be multiple commits for db migrations and content-type changes and a desired order of execution is needed during deployments.
Both migrations and content type changes are to be maintained with time stamps and the order of their execution can be preserved. Having the content-type changes to generate migrations would help.


