feat: enhance location handling and localization; improve fallback mechanisms and unify type definitions

libs/api/src/lib/features/location/index.ts

@@ -0,0 +1 @@
+export * from './location.types';

libs/api/src/lib/features/location/location.types.ts

@@ -0,0 +1,47 @@
+/** Shared location contract — mirrors the `iam.locations` tree in emaapi. */
+
+import type { Bilingual } from '../licensing/licensing.types';
+
+/**
+ * One node of the location tree.
+ *
+ * Both apps read the same `/locations` route, so the model lives here rather
+ * than in each app's own feature folder — the two hand-maintained copies had
+ * already drifted (the portal's lacked `locationType`, `children` and the
+ * timestamps, and its query accepted no `parentId` filter even though the
+ * backend supports one).
+ *
+ * `names` is `Bilingual`, the backend's `LocaleValidationDto`: seeded location
+ * names carry `om` and `so` alongside `en`/`am`, which the previous
+ * `{ en, am }` pair made unreachable.
+ */
+export interface Location {
+  id: string;
+  code: string;
+  names: Bilingual;
+  locationTypeId: string;
+  parentId: string | null;
+  locationType?: LocationType;
+  children?: Location[];
+  createdAt?: string;
+  updatedAt?: string;
+}
+
+/**
+ * A level in the tree. `level` orders them (City 1 → Sub-city 2 → Woreda 3 →
+ * Kebele 4); `code` is what both sides key behaviour off, so it is the field to
+ * match on rather than the display name.
+ */
+export interface LocationType {
+  id: string;
+  code: string;
+  names: Bilingual;
+  level: number;
+  createdAt?: string;
+  updatedAt?: string;
+}
+
+export interface ListResponse<T> {
+  count: number;
+  items: T[];
+}