Refactor API structure and add comprehensive user management features

- Restructure API v1 with improved serializers organization
- Add user deletion requests and moderation queue system
- Implement bulk moderation operations and permissions
- Add user profile enhancements with display names and avatars
- Expand ride and park API endpoints with better filtering
- Add manufacturer API with detailed ride relationships
- Improve authentication flows and error handling
- Update frontend documentation and API specifications

.clinerules/cline_rules.md

@@ -0,0 +1,54 @@
+## Mandatory Development Rules
+
+### API Organization
+- **MANDATORY NESTING**: All API directory structures MUST match URL nesting patterns. No exceptions.
+- **NO TOP-LEVEL ENDPOINTS**: URLs must be nested under top-level domains. Avoid creating separate top-level API endpoints - nest them under existing domains instead.
+
+### Data Model Rules
+- **RIDE TYPES vs RIDE MODELS**: These are separate concepts for ALL ride categories:
+  - **Ride Types**: How rides operate (e.g., "inverted", "trackless", "spinning", "log flume", "monorail")
+  - **Ride Models**: Specific manufacturer products (e.g., "B&M Dive Coaster", "Vekoma Boomerang")
+  - Individual rides reference BOTH the model (what product) and type (how it operates)
+  - Ride types must be available for ALL ride categories, not just roller coasters
+
+### Development Commands
+- **Django Server**: Always use `uv run manage.py runserver_plus` instead of `python manage.py runserver`
+- **Django Migrations**: Always use `uv run manage.py makemigrations` and `uv run manage.py migrate` instead of `python manage.py`
+- **Package Management**: Always use `uv add <package>` instead of `pip install <package>`
+- **Django Management**: Always use `uv run manage.py <command>` instead of `python manage.py <command>`
+
+### ThrillWiki Project Rules
+- **Domain Structure**: Parks contain rides, rides have models, companies have multiple roles (manufacturer/operator/designer)
+- **Media Integration**: Use CloudflareImagesField for all photo uploads with variants and transformations
+- **Tracking**: All models use pghistory for change tracking and TrackedModel base class
+- **Slugs**: Unique within scope (park slugs global, ride slugs within park, ride model slugs within manufacturer)
+- **Status Management**: Rides have operational status (OPERATING, CLOSED_TEMP, SBNO, etc.) with date tracking
+- **Company Roles**: Companies can be MANUFACTURER, OPERATOR, DESIGNER, PROPERTY_OWNER with array field
+- **Location Data**: Use PostGIS for geographic data, separate location models for parks and rides
+- **API Patterns**: Use DRF with drf-spectacular, comprehensive serializers, nested endpoints, caching
+- **Photo Management**: Banner/card image references, photo types, attribution fields, primary photo logic
+- **Search Integration**: Text search, filtering, autocomplete endpoints, pagination
+- **Statistics**: Cached stats endpoints with automatic invalidation via Django signals
+
+### CRITICAL DOCUMENTATION RULE
+- CRITICAL: After every change, it is MANDATORY to update docs/frontend.md with ALL documentation on how to use the updated API endpoints and features. Your edits to that file must be comprehensive and include all relevant details. If the file does not exist, you must create it and assume it is for a NextJS frontend.
+- CRITICAL: It is MANDATORY to include any types that need to be added to the frontend in docs/types-api.ts for NextJS as the file would appear in `src/types/api.ts` in the NextJS project exactly. Again, create it if it does not exist. Make sure it is in sync with docs/api.ts. Full type safety.
+- CRITICAL: It is MANDATORY to include any new API endpoints in docs/lib-api.ts for NextJS as the file would appear in `/src/lib/api.ts` in the NextJS project exactly. Again, create it if it does not exist. Make sure it is in sync with docs/types.ts. Full type safety.
+
+### CRITICAL DATA RULE
+- **NEVER MOCK DATA**: You are NEVER EVER to mock any data unless it's ONLY for API schema documentation purposes. All data must come from real database queries and actual model instances. Mock data is STRICTLY FORBIDDEN in all API responses, services, and business logic.
+
+### CRITICAL DOMAIN SEPARATION RULE
+- **OPERATORS AND PROPERTY_OWNERS ARE FOR PARKS ONLY**: Company roles OPERATOR and PROPERTY_OWNER are EXCLUSIVELY for parks domain. They should NEVER be used in rides URLs or ride-related contexts. Only MANUFACTURER and DESIGNER roles are for rides domain.
+- **Correct URL patterns**:
+  - Parks: `/parks/{park_slug}/` and `/parks/` showing a global list of parks with all possible fields.
+  - Rides: `/parks/{park_slug}/rides/{ride_slug}/` and `/rides/` showing a global list of rides with all possible fields.
+  - Parks Companies: `/parks/operators/{operator_slug}/` and `/parks/owners/{owner_slug}/` and `/parks/operators/` and `/parks/owners/` showing a global list of park operators or owners respectively with filter options based on all fields.
+  - Rides Companies: `/rides/manufacturers/{manufacturer_slug}/` and `/rides/designers/{designer_slug}/` and `/rides/manufacturers/` and `/rides/designers/` showing a global list of ride manufacturers or designers respectively with filter options based on all fields.
+- **NEVER mix these domains** - this is a fundamental and DANGEROUS business rule violation.
+
+### CRITICAL PHOTO MANAGEMENT RULE
+- **Use CloudflareImagesField**: All photo uploads must use CloudflareImagesField with variants and transformations.
+- **Photo Types**: Clearly define and use photo types (e.g., banner, card) for all images.
+- **Attribution Fields**: Include attribution fields for all photos, specifying the source and copyright information.
+- **Primary Photo Logic**: Implement logic to determine the primary photo for each model, ensuring consistency across the application.

.clinerules/django-moderation-integration.md

@@ -0,0 +1,38 @@
+## Brief overview
+Guidelines for integrating new Django moderation systems while preserving existing functionality, based on ThrillWiki project patterns. These rules ensure backward compatibility and proper integration when extending moderation capabilities.
+
+## Integration approach
+- Always preserve existing models and functionality when adding new moderation features
+- Use comprehensive model integration rather than replacement - combine original and new models in single files
+- Maintain existing method signatures and property aliases for backward compatibility
+- Fix field name mismatches systematically across services, selectors, and related components
+
+## Django model patterns
+- All models must inherit from TrackedModel base class and use pghistory for change tracking
+- Use proper Meta class inheritance: `class Meta(TrackedModel.Meta):`
+- Maintain comprehensive business logic methods on models (approve, reject, escalate)
+- Include property aliases for backward compatibility when field names change
+
+## Service and selector updates
+- Update services and selectors to match restored model field names systematically
+- Use proper field references: `user` instead of `submitted_by`, `created_at` instead of `submitted_at`
+- Maintain transaction safety with `select_for_update()` in services
+- Keep comprehensive error handling and validation in service methods
+
+## Migration strategy
+- Create migrations incrementally and handle field changes with proper defaults
+- Test Django checks after each major integration step
+- Apply migrations immediately after creation to verify database compatibility
+- Handle nullable field changes with appropriate migration prompts
+
+## Documentation requirements
+- Update docs/types-api.ts with complete TypeScript interface definitions
+- Update docs/lib-api.ts with comprehensive API client implementation
+- Ensure full type safety and proper error handling in TypeScript clients
+- Document all new API endpoints and integration patterns
+
+## Testing and validation
+- Run Django system checks after each integration step
+- Verify existing functionality still works after adding new features
+- Test both original workflow and new moderation system functionality
+- Confirm database migrations apply successfully without errors