Require a planned day to carry its wish and pinned state

Both fields were made optional to avoid editing test files that were out of
scope at the time, but the API populates them on every planned day, so the
optionality described nothing real and quietly loosened the contract between
the wire format and the client — which is where this codebase has historically
gone wrong.

The inline objects that forced the compromise now go through the typed test
factory instead, so the next field added to a planned day is a one-line change
rather than another round of this.

frontend/src/types/entities.ts

@@ -105,13 +105,10 @@ export interface PlannedLeaveDay {
   dayType: 'sjukpenning' | 'lagsta' | 'vacation'
   isDubbeldag: boolean
   // Which `LeaveWish` produced this day; null/omitted means ad-hoc (not tied to a wish).
-  // Optional (rather than required) so existing object literals elsewhere in the
-  // codebase that predate this field keep type-checking; `toPlannedLeaveDay` in
-  // services/api.ts always populates it from the wire response.
-  wishId?: string | null
+  // `toPlannedLeaveDay` in services/api.ts always populates it from the wire response.
+  wishId: string | null
   // True when the user hand-edited this day's type — the planner must not retype it.
-  // Optional for the same reason as `wishId` above.
-  isPinned?: boolean
+  isPinned: boolean
   createdAt: string
   updatedAt: string
 }