feat: Implement Entity Suggestion Manager and Modal components

- Added EntitySuggestionManager.vue to manage entity suggestions and authentication.
- Created EntitySuggestionModal.vue for displaying suggestions and adding new entities.
- Integrated AuthManager for user authentication within the suggestion modal.
- Enhanced signal handling in start-servers.sh for graceful shutdown of servers.
- Improved server startup script to ensure proper cleanup and responsiveness to termination signals.
- Added documentation for signal handling fixes and usage instructions.

.clinerules

@@ -1,83 +1,44 @@
-# Project Startup Rules
+# Project Startup & Development Rules
 
-## Development Server
-IMPORTANT: Always follow these instructions exactly when starting the development server:
+## Server & Package Management
+- **Starting the Dev Server:** Always assume the server is running and changes have taken effect. If issues arise, run:
+   ```bash
+   $PROJECT_ROOT/shared/scripts/start-servers.sh
+   ```
+- **Python Packages:** Only use UV to add packages:
+   ```bash
+   cd $PROJECT_ROOT/backend && uv add <package>
+   ```
+- **Django Commands:** Always use `uv run manage.py <command>` for all management tasks (migrations, shell, superuser, etc.). Never use `python manage.py` or `uv run python manage.py`.
 
-FIRST, assume the server is running. Always. Assume the changes have taken effect.
+## Frontend API URL Rules
+- **Vite Proxy:** Always check `frontend/vite.config.ts` for proxy rules before changing frontend API URLs.
+- **URL Flow:** Understand how frontend URLs are rewritten by Vite proxy (e.g., `/api/auth/login/` → `/api/v1/auth/login/`).
+- **Verification:** Confirm proxy behavior via config and browser network tab. Only change URLs if proxy is NOT handling rewriting.
+- **Common Mistake:** Don’t assume frontend URLs are wrong due to proxy configuration.
 
-IF THERE IS AN ISSUE WITH THE SERVER, run the following command exactly:
-```bash
-lsof -ti :8000 | xargs kill -9; find . -type d -name "__pycache__" -exec rm -r {} +; cd backend && uv run manage.py runserver_plus && cd ../frontend && pnpm run dev
+## Entity Relationship Patterns
+- **Park:** Must have Operator (required), may have PropertyOwner (optional), cannot reference Company directly.
+- **Ride:** Must belong to Park, may have Manufacturer/Designer (optional), cannot reference Company directly.
+- **Entities:** 
+   - Operators: Operate parks.
+   - PropertyOwners: Own park property (optional).
+   - Manufacturers: Make rides.
+   - Designers: Design rides.
+   - All entities can have locations.
+- **Constraints:** Operator and PropertyOwner can be same or different. Manufacturers and Designers are distinct. Use proper foreign keys with correct null/blank settings.
 
-Note: These steps must be executed in this exact order to ensure consistent behavior. If server does not start correctly, fix the error in accordance with the error details as best you can.
-
-## Package Management
-IMPORTANT: When a Python package is needed, only use UV to add it:
-```bash
-uv add <package>
-```
-Do not attempt to install packages using any other method.
-
-## Django Management Commands
-IMPORTANT: When running any Django manage.py commands (migrations, shell, etc.), always use UV:
-```bash
-uv run manage.py <command>
-```
-This applies to all management commands including but not limited to:
-- Making migrations: `uv run manage.py makemigrations`
-- Applying migrations: `uv run manage.py migrate`
-- Creating superuser: `uv run manage.py createsuperuser` and possible echo commands before for the necessary data input.
-- Starting shell: `uv run manage.py shell` and possible echo commands before for the necessary data input.
-
-NEVER use `python manage.py` or `uv run python manage.py`. Always use `uv run manage.py` directly.
-
-## Entity Relationship Rules
-IMPORTANT: Follow these entity relationship patterns consistently:
-
-# Park Relationships
-- Parks MUST have an Operator (required relationship)
-- Parks MAY have a PropertyOwner (optional, usually same as Operator)
-- Parks CANNOT directly reference Company entities
-
-# Ride Relationships
-- Rides MUST belong to a Park (required relationship)
-- Rides MAY have a Manufacturer (optional relationship)
-- Rides MAY have a Designer (optional relationship)
-- Rides CANNOT directly reference Company entities
-
-# Entity Definitions
-- Operators: Companies that operate theme parks (replaces Company.owner)
-- PropertyOwners: Companies that own park property (new concept, optional)
-- Manufacturers: Companies that manufacture rides (replaces Company for rides)
-- Designers: Companies/individuals that design rides (existing concept)
-- IMPORTANT: All entities can have locations. 
-
-# Relationship Constraints
-- Operator and PropertyOwner are usually the same entity but CAN be different
-- Manufacturers and Designers are distinct concepts and should not be conflated
-- All entity relationships should use proper foreign keys with appropriate null/blank settings
-
-- You are to NEVER assume that blank output means your fixes were correct. That assumption can lead to further issues down the line.
-- ALWAYS verify your changes by testing the affected functionality thoroughly.
-- ALWAYS use context7 to check documentation when troubleshooting. It contains VITAL documentation for any and all frameworks, modules, and packages.
-- ALWAYS document your code changes with conport and the reasoning behind them.
-- ALWAYS include relevant context and information when making changes to the codebase.
-- ALWAYS ensure that your code changes are properly tested and validated before deployment.
-- ALWAYS communicate clearly and effectively with your team about any changes you make.
-- ALWAYS be open to feedback and willing to make adjustments as necessary.
-- ALWAYS strive for continuous improvement in your work and processes.
-- ALWAYS prioritize code readability and maintainability.
-- ALWAYS keep security best practices in mind when developing and reviewing code.
-- ALWAYS consider performance implications when making changes to the codebase.
-- ALWAYS be mindful of the impact of your changes on the overall system architecture.
-- ALWAYS keep scalability in mind when designing new features or modifying existing ones.
-- ALWAYS consider the potential for code reuse and modularity in your designs.
-- ALWAYS document your code with clear and concise comments.
-- ALWAYS keep your code DRY (Don't Repeat Yourself) by abstracting common functionality into reusable components.
-- ALWAYS use meaningful variable and function names to improve code readability.
-- ALWAYS handle errors and exceptions gracefully to improve the user experience.
-- ALWAYS log important events and errors for troubleshooting purposes.
-- ALWAYS consider if there may be an existing module or package that can be leveraged before creating new functionality from scratch.
-- ALWAYS keep documentation up to date with any code changes.
-- ALWAYS consider if there are any potential security vulnerabilities in your code.
-- ALWAYS consider if there are any potential performance bottlenecks in your code.
+## General Best Practices
+- Never assume blank output means success—always verify changes by testing.
+- Use context7 for documentation when troubleshooting.
+- Document changes with conport and reasoning.
+- Include relevant context and information in all changes.
+- Test and validate code before deployment.
+- Communicate changes clearly with your team.
+- Be open to feedback and continuous improvement.
+- Prioritize readability, maintainability, security, performance, scalability, and modularity.
+- Use meaningful names, DRY principles, clear comments, and handle errors gracefully.
+- Log important events/errors for troubleshooting.
+- Prefer existing modules/packages over new code.
+- Keep documentation up to date.
+- Consider security vulnerabilities and performance bottlenecks in all changes.