fix: resync aux timer names on project load, consolidate name handling

Addresses the review findings on the aux timer naming feature.

- Aux timer names are project data, but they were only applied at
  bootstrap and on a settings POST. Loading another project left the
  previous project's names in the runtime store, so the controls and
  views disagreed with the settings panel until a restart. The names are
  now applied when a project is loaded, and patching the current project
  settings applies them and sends a settings refetch to the clients
  (loading a project already triggers a full refetch via the rundown).
- Consolidate the name handling into a single normaliser in ontime-utils,
  used by the project file parser, the API validation and to build the
  default value. This creates the property when importing project files
  saved before the feature existed, and enforces the name length limit
  server side rather than only in the form.
- loadNames normalises its input, so the runtime state is consistent
  regardless of the shape of the stored settings.
- Clarify that auxTimerNames is ordered (index 0 is aux timer 1), and
  derive the settings form from the shared aux timer count.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WCZejVTzuAY3tHTE6nB3JH

packages/types/src/definitions/core/Settings.type.ts

@@ -6,6 +6,9 @@ export type Settings = {
   operatorKey: null | string;
   timeFormat: TimeFormat;
   language: string;
-  /** Custom names for the aux timers, indexed by aux timer (1, 2, 3). Empty string falls back to the default label */
+  /**
+   * Custom names for the aux timers, one entry per aux timer in order (index 0 is aux timer 1).
+   * An empty string means the timer is unnamed and consumers show the default label
+   */
   auxTimerNames: string[];
 };