Refactor architecture documentation and enhance security features

- Updated architecture constraints documentation to include detailed sections on technical, organizational, regulatory, environmental, and performance constraints.
- Created separate markdown files for each type of constraint for better organization and clarity.
- Revised the architecture scope section to provide a clearer overview of the system's key areas.
- Enhanced the solution strategy documentation with detailed explanations of the client-server architecture, technology choices, trade-offs, and future considerations.
- Added comprehensive descriptions of backend and frontend components, middleware, and utilities in the architecture documentation.
- Migrated UI, templates, and styling notes to a dedicated section for better structure.
- Updated requirements.txt to include missing dependencies.
- Refactored user authentication logic in the users.py and security.py files to improve code organization and maintainability, including the integration of OAuth2 password bearer token handling.

docs/architecture/04_strategy/04_03_trade_offs.md

@@ -0,0 +1,14 @@
+---
+title: '04.03 — Trade-offs'
+description: 'Discussion of trade-offs made in the CalMiner architecture.'
+---
+
+# 04.03 — Trade-offs
+
+- **Server-Rendered vs. SPA**: Opted for server-rendered templates over a single-page application (SPA) to reduce complexity and improve initial load times, at the cost of some interactivity.
+- **Synchronous vs. Asynchronous**: While FastAPI supports async operations, the initial implementation focuses on synchronous request handling for simplicity, with plans to introduce async features as needed.
+- **Monolithic vs. Microservices**: The initial architecture follows a monolithic approach for ease of development and deployment, with the possibility of refactoring into microservices as the system scales.
+- **In-Memory Caching**: Implementing Redis for caching introduces additional infrastructure complexity but significantly enhances performance for read-heavy operations.
+- **Database Choice**: PostgreSQL was chosen over NoSQL alternatives due to the structured nature of the data and the need for complex querying capabilities, despite potential scalability challenges.
+- **Technology Familiarity**: Selected technologies align with the team's existing skill set to minimize the learning curve and accelerate development, even if some alternatives may offer marginally better performance or features.
+- **Extensibility vs. Simplicity**: The architecture is designed to be extensible for future features (e.g., Monte Carlo simulation engine) while maintaining simplicity in the initial implementation to ensure timely delivery of core functionalities.