fix(web-frontend): Coerce preference array fields to prevent TypeError

[sentry]

This PR addresses the TypeError: shiftCount.person.join is not a function by ensuring that array-typed preference fields are properly normalized during data loading and by adding defensive checks in the rendering component.

Changes Made:

• web-frontend/src/hooks/useSchedulingData.ts:
  • Replaced the convertArrayIdsToString utility with a new normalizePrefArray function.
  • normalizePrefArray now actively coerces non-array values (e.g., single strings or numbers from older saved data) into single-element arrays and ensures all IDs are stringified. It also handles null/undefined values by returning early.
  • Applied normalizePrefArray to all relevant array-typed preference fields (e.g., shiftType, qualifiedPeople, date, person, pattern, countDates, countShiftTypes, people1, people2, shiftTypes) within the newState.preferences.forEach loop.
• web-frontend/src/app/shift-counts/page.tsx:
  • Added defensive Array.isArray() checks around shiftCount.person, shiftCount.countDates, and shiftCount.countShiftTypes before calling .join(', ') to provide robustness against any data that might bypass the normalization or for future-proofing.

Reasoning:
The root cause was that shiftCount.person (and similar fields like countDates, countShiftTypes) could be a string or number at runtime, rather than the expected string[], leading to a TypeError when .join() was called. This was due to older persisted data formats and the previous normalization logic in useSchedulingData.ts silently returning for non-array inputs. The fix ensures these fields are consistently arrays, preventing runtime errors and improving data integrity.

Fixes JAVASCRIPT-NEXTJS-H