WIP: Extract shift apply/approve workflow into service layer

[LoopyB]

Sprint 2 – Service Layer Pilot (Shift Apply/Approve)

Overview

This PR introduces a small, targeted service-layer refactor for the shift application and approval workflow. The goal is to improve separation of concerns and enable more effective backend testing without impacting existing functionality.

Changes

• Extracted business logic from:
  • applyForShift
  • approveShift
• Introduced shiftApplication.service.js to encapsulate workflow logic
• Refactored controller to act as a thin layer:
  • handles request/response only
  • delegates decision-making to the service layer

Design Rationale

Previously, controllers contained a mix of HTTP handling and business logic, making them harder to maintain and test.

This change introduces a clearer architecture:
route → controller → service → model

This separation:

• isolates business rules from Express concerns
• improves readability and maintainability
• enables focused unit testing of domain logic

Testing Approach

• Service layer is now structured to support direct unit testing
• Test scenarios identified include:
  • duplicate application prevention
  • invalid shift states (past/started/assigned)
  • approval rules and guard validation
• Implementation of tests is being progressed alongside this refactor

Impact

• Establishes a reusable pattern for future backend development
• Reduces coupling between controllers and business logic
• Provides a foundation for improving backend reliability through testing

Scope

• Limited to shift apply/approve workflow only
• No changes to API contracts or external behaviour
• No large-scale refactor introduced

---

Lint / CI Note

This PR passes lint for the modified files:

• shift.controller.js
• shiftApplication.service.js

Remaining lint errors are pre-existing in the repository and unrelated to this change. These currently block backend PR merges and should be addressed separately as a cleanup task.