Enhancement: Built-in Git Repository per Project

### 🔖 Enhancement description Feature Request: Built-in Git Repository per Project Problem Appwrite centralises the backend — database, auth, storage, edge functions — but application code lives outside it, on a separate Git platform. This creates unnecessary friction: Every collaborator needs an account on a third-party service. Onboarding means granting access in two places. The link between code changes and database migrations is split across two platforms with no native connection. This is especially painful for less technical users and small teams where simplicity matters more than advanced tooling. Proposed Solution A Git repository hosted natively inside each InsForge project, with: A Git remote accessible via HTTPS using existing InsForge credentials. A basic web UI to browse commits, branches, and open/merge pull requests. Automatic migration runs on merge to main (InsForge already owns the database — this is a natural fit). Access control tied to existing project members and roles. Why It Matters With built-in Git, Appwrite becomes a single place to build, collaborate, and ship. No second platform, no second account, no split context between code and schema history. It reduces onboarding time and removes a real barrier for teams that don't need the full power of GitHub or GitLab — they just need to ship together. Priority Signal This would be a meaningful differentiator for teams building internal tools and MVPs where speed of collaboration is the priority. ### 🎤 Pitch Why It Matters With built-in Git, Appwrite becomes a single place to build, collaborate, and ship. No second platform, no second account, no split context between code and schema history. It reduces onboarding time and removes a real barrier for teams that don't need the full power of GitHub or GitLab — they just need to ship together. ### 👀 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 o…