Feat: auth middleware

[kbventures]

Summary

APIs \ Auth	Login	Access level
Auth
POST /auth/sign-up	-	-
GET /auth/activate	-	-
POST /auth/sign-in	-	-
Profiles
GET /profiles	-	-
GET /profiles/{id}	-	-
POST /profiles	O	organizer
PATCH /profiles/{id}	O	admin or volunteer with own id
DELETE /profiles/{id}	O	admin
Teams
GET /teams	O	volunteer
GET /teams/{id}	O	volunteer
POST /teams	O	admin
PATCH /teams/{id}	O	organizer
DELETE /teams/{id}	O	admin

Tests

Additional information

• used the middleware property in createRoute() of zod-openapi

[kbventures]

Role-based service VS Seperate Routes

| Role-Based Service | - Centralized logic
- Easy to modify rules
- Good for complex permissions | - More initial setup
- More complex structure |

| Separate Routes | - Clear middleware chain
- Reusable role checks
- Easy to add new role-based routes | - More files to manage
- Need to maintain middleware separately |

The middleware approach (Option 2) is particularly powerful because:
Middleware is reusable across different routes
Role checks are separated from business logic
Easy to add new role-based routes
Clear separation of concerns

There are other options but I didn't really think single route was a good idea as we'd probably end up having to refactor it later.

[madcampos]

3 threads left to resolve, otherwise looks good to me.

NOTE: All of these are non-blocking and/or require more discussion, so I'm approving this PR for us to move forward and resolve those issues separately.

• multiple middlewares
• re-request sign-in
• multiple db queries on auth middleware