Implement Case intake and management

[mattburnett-repo]

Summary

Implement the first Core Feature advertised on the app start page: Case intake and management.

Design context: See DESIGN_NOTES.md for requirements, architecture, and conventions. The following scope aligns with DESIGN_NOTES §1 (Case intake via forms or APIs; assignment, tracking, and status updates), §3 (ColdBox handlers/models/views), §6 (native templates, responsive/progressive enhancement), §7 (TestBox coverage), and §12 (ColdBox conventions, WireBox DI, accessible UI).

Current state

• CaseService exists with listActive(), listAll(includeArchived), archiveCase(), restoreCase().
• Cases entity (ORM) exists with title, description, status, creator, assignedTo, archive fields, etc.
• No Cases UI: no handler, no views. Users cannot list, view, create, or edit cases from the app.

Scope (MVP)

• Cases handler (handlers/Cases.cfc) with actions: index (list), view (detail), optionally new/create, edit/update. Use WireBox to inject CaseService; follow ColdBox handler conventions.
• Views: views/cases/index.cfm (list of cases), views/cases/view.cfm (single case detail). Use prc from handler; reuse existing layout. ColdFusion native templates; responsive/mobile-first and accessible where applicable (DESIGN_NOTES §6, §12).
• Routing: Use convention (/cases/index, /cases/view?id=...) or add explicit routes in config/Router.cfc for cleaner URLs.
• Navigation: Add a link from the start page (e.g. under Core Features) to the case list so "Case intake and management" is actionable.
• Tests: Add or extend TestBox specs (integration or unit) for the new Cases handler and behavior so case list/view (and create/edit if in scope) are covered (DESIGN_NOTES §7).

From DESIGN_NOTES (relevant to this feature)

• Intake: Case intake via forms or APIs (MVP can be form-based; API endpoint can be a follow-up).
• Assignment & status: Assignment (assignedTo), tracking, and status updates are part of the Cases model; ensure they are visible and editable in the case detail/form where appropriate.
• Case workflows: Defining or refining status workflows (e.g. valid transitions) can be part of this issue or a follow-up, per DESIGN_NOTES "Suggested Next Steps."

Out of scope for this issue

• Document upload (separate feature).
• Staff communication tools / audit UI / role-based access (later issues).
• Archive/restore from UI can be a follow-up if not in MVP.
• REST/API endpoint for case intake (can be added later if forms are done first).

Acceptance criteria

• User can open a "Cases" or "View cases" link from the home page and see a list of (active) cases.
• User can open a case and see its details (title, description, status, dates, creator, assignedTo, etc.).
• Optional: user can create a new case and edit an existing case (if included in MVP); assignment and status are reflected.
• New handler and views are covered by tests (TestBox).