Feature: Enforce "Creator Ownership" and Permission Validation for Client SDK

### 🔖 Enhancement description **Problem:** When using the Client SDK with `Document Security` enabled, the backend trusts the `permissions` array provided by the client during `createDocument`. This creates a security/integrity loophole in multi-tenant applications. A malicious user (User A) can create a document but assign permissions *only* to User B (e.g., `Permission.read(Role.user('user-b'))`). This allows "Data Spoofing" attacks. For example, in an invoicing app, User A can inject a fake invoice into User B's dashboard. User B sees it as a legitimate document because the query filters allow it, but the data source is malicious. **Current Workaround:** The only way to prevent this is to disable `create` permissions on the Collection and route all writes through Appwrite Functions. While secure, this adds significant complexity, latency, and maintenance overhead for simple CRUD operations. **Proposed Solution:** I suggest adding a configuration option in the Collection Settings (e.g., **"Enforce Creator Ownership"**). If enabled: 1. Appwrite automatically forces `read/update/delete` permissions for the `user:{id}` of the requestor. 2. Optionally: The backend rejects the request if the client tries to assign permissions to specific Users or Teams they do not belong to. ### 🎤 Pitch Implementing this feature would significantly improve the **"Secure by Default"** philosophy of Appwrite. 1. **Data Integrity:** It prevents users from polluting other users' dashboards with unauthorized data without needing complex backend logic. 2. **Developer Experience (DX):** Developers can stick to the Client SDK for standard CRUD apps (SaaS, To-Do, CRM) without being forced to spin up Cloud Functions just to secure the `create` operation. 3. **Competitiveness:** This brings Appwrite closer to the granular control offered by SQL RLS policies (Supabase) or Security Rules (Firebase), where developers can strictly define *who* can create data for *whom*. ### 👀 Have you spent …