Merged PR 2374: addeding domain layer extrraction

# Summary

This PR introduces a **Case Lifecycle Domain Boundary** to centralize lifecycle decision logic and reduce coupling within the appeals application.

The work is **behaviour-preserving** and introduces no intentional changes to business rules, CRM integrations, translations, dashboards, API routes, or user-facing functionality.

## What was added

New lifecycle boundary:

```text
lib/domain/case-lifecycle/
```

Key responsibilities extracted:

- Specialist process normalization
- Appeal type mapping
- Specialist process stage override mapping
- Stage case-type resolution
- Stage catalogue lookup
- Closed-case status recognition
- Lifecycle stage index resolution
- Lifecycle stage status assignment

## Behaviour preserved

Characterization tests were added before each extraction to preserve:

- Appeal type mapping and aliases
- Specialist process handling
- Lifecycle stage progression
- Closed-case handling
- Status assignment (`complete`, `in-progress`, `not-started`)
- Existing ROW behaviour
- Existing `statuscode` lifecycle semantics

Closed-case recognition remains unchanged for:

```text
1000
5
6
846040013
846040059
846040060
```

## Documentation

Added:

```text
lib/domain/case-lifecycle/README.md
```

Documenting:

- Boundary ownership
- Non-goals
- Lifecycle invariants
- Known architectural constraints
- Future extraction roadmap

## Testing

Added lifecycle characterization coverage for:

- Stage wrapper behaviour
- Specialist process normalization
- Appeal type mapping
- Specialist process stage mapping
- Stage case-type resolution
- Stage catalogue lookup
- Progress behaviour
- Closed-case status handling
- Stage index resolution
- Stage status assignment

## Validation

- Lifecycle characterization tests passed
- `npm run lint` passed with no errors

## Out of Scope

No changes to:

- Stage catalogue ownership
- Representation eligibility
- Dashboard calculations
- CRM/OData queries
- API routes
- Redux state
- EN/CY translations
- Event visibility logic

## Risk

**Low risk**

The refactor was delivered through small, characterization-first slices with no functional changes intended.

Related work items: #23527

pages/case/[ticketnumber].js

@@ -16,6 +16,7 @@ import {
 import { getBasicSearch } from "../../actions/services/searchService";
 import Breadcrumbs from "../../components/breadcrumbs";
 import Case from "../../components/case";
+import { normalizeSpecialistProcess } from "../../lib/domain/case-lifecycle";
 import CookieBanner from "../../components/cookieBanner";
 import Footer from "../../components/footer";
 import Header from "../../components/header";
@@ -221,16 +222,9 @@ export const getServerSideProps = wrapper.getServerSideProps(
                         "appealType":
                             searchResultsObj.value[0].pinswg_appealcasetype,
                         "showLoginCheck": true,
-                        "specialistProcess":
+                        "specialistProcess": normalizeSpecialistProcess(
                             searchDetailsObj[0].value[0]
-                                ?.pinswg_speacialistcaseprocess != null ||
-                            searchDetailsObj[0].value[0]
-                                ?.pinswg_specialistcaseprocess != null
-                                ? searchDetailsObj[0].value[0]
-                                      ?.pinswg_speacialistcaseprocess ||
-                                  searchDetailsObj[0].value[0]
-                                      ?.pinswg_specialistcaseprocess
-                                : ""
+                        )
                     })
                 );
             }