Database migration schema

### 🔖 Enhancement description

- Non-destructive / Seamless schema migrations: Changing an attribute (like its type or format) should not drop the column and wipe existing data.
- Atomic rollbacks: If an error occurs while applying schema changes via the CLI, the process should roll back to the last working state entirely, rather than leaving the database schema in a broken or partially updated state.

### 🎤 Pitch

In my opinion, the current “migration” via the Appwrite CLI and “appwrite.config.json” isn't really a migration at all.

The biggest problem: A single change to an existing attribute automatically leads to data loss, which is extremely critical in a production environment. And having to write a separate script for something like this isn’t worth the effort for such a basic task, in my opinion.

While this might be acceptable for side projects or early MVP stages, it becomes a massive deal-breaker when deciding whether to scale a SaaS product with Appwrite.

Furthermore, the lack of atomic rollbacks means if a CLI push fails halfway through, the schema doesn't revert to its last known good configuration, it simply breaks, leaving the database in an inconsistent state.

Feel free to correct me if I'm wrong.

### 👀 Have you spent some time to check if this issue has been raised before?

- [x] I checked and didn't find similar issue

### 🏢 Have you read the Code of Conduct?

- [x] I have read the [Code of Conduct](https://github.com/appwrite/.github/blob/main/CODE_OF_CONDUCT.md)

Start by reading the Appwrite CLI migration path and how appwrite.config.json changes are applied. Reproduce a schema update and a failed multi-step push to understand the current behavior. Done means existing data survives attribute changes and a failed CLI migration restores the last working schema.

Written by the indexing model from the issue text.