feat: Map enum field types to proper GraphQL enum types instead of String

### 🔖 Enhancement description Currently, enum field types in Appwrite's GraphQL schema are mapped to generic `String` types as a placeholder, as seen in: `src/Appwrite/GraphQL/Types/Mapper.php` line 456: ```php 'enum' => static::model("{$prefix}String"), // TODO: Add enum type (breaking change if added) ``` This means enum attributes defined in Appwrite collections are exposed as plain strings in the GraphQL API, losing all type information about valid values. ### 🎤 Pitch This enhancement matters for three reasons: **1. Type Safety** When a developer defines an enum attribute with values like ["draft", "published", "archived"], the GraphQL API currently accepts any arbitrary string — including invalid values like "banana". Proper enum types would reject invalid values at the schema level before they ever reach the database. **2. Developer Experience** GraphQL's biggest advantage over REST is schema introspection. When clients query the schema, they should be able to see exactly which values are valid for an enum field. Right now they see `String` — which tells them nothing. With proper enum types, IDEs can autocomplete valid values and catch mistakes instantly. **3. Accurate Schema Representation** The GraphQL schema should be a true reflection of the data model. An enum attribute with 3 allowed values is fundamentally different from a free-text string field. Mapping both to `String` makes the schema misleading. **Example of current behavior:** mutation { createDocument( databaseId: "main", collectionId: "posts", documentId: "unique()", data: { status: "banana" } # ← accepted, but invalid! ) { _id } } **Example of expected behavior:** mutation { createDocument( data: { status: PUBLISHED } # ← only valid enum values accepted ) { _id } } This is noted as a TODO in the codebase itself, signaling the Appwrite team already identified this as a gap. This issue is to formally track and prioritize it. Note: As the…