chore: automate MomentTimezoneInclude endYear bump

[hotinglok]

Why

The endYear passed to MomentTimezoneInclude needs bumping each year so the bundled moment-timezone data covers the upcoming year. It's currently maintained by hand across four config files, which drift out of sync (two say 2026, two say 2025).

What

Adds automation to bump endYear to the upcoming year, kept manual (opens a PR for human review/merge — nothing auto-merges or auto-deploys):

• scripts/updateMomentTimezoneYear.js — dependency-free node script that sets endYear to currentYear + 1 across the four build config files (.storybook/main.ts, cypress.config.ts, ws-nextjs-app/next.config.js, ws-nextjs-app/cypress.config.ts). Only targets MomentTimezoneInclude calls, so the test fixtures are untouched. Supports --check mode (exits non-zero if stale) for optional CI gating.
• .github/workflows/update-moment-timezone-year.yml — scheduled workflow (cron: '0 6 1 12 *', i.e. 06:00 UTC on 1 December each year, plus workflow_dispatch) that runs the script and opens a PR.
• package.json — adds yarn update-moment-timezone-year.

Notes

• The year is a single build-time value with no per-environment overrides, so the bump applies uniformly to test/preview/live once merged and built.
• The auto-PR uses the default GITHUB_TOKEN, so required CI checks may need a manual nudge (empty commit / reopen) to run on the bot's PR. Can switch to a PAT/App token later if desired.

[copilot]

[elvinasv]

Hi, as discussed yesterday, what was the main reason for not using the dynamic approach i.e. new Date().getFullYear() + 1 (#14209)?

We looked at the script automation approach suggested by Copilot, but it felt a little more complex than necessary for our use case. We're happy to reconsider it, if there are benefits we're not taking into account.