fix(dlp): guard the two remaining midnight-crossing sites against host TZ

[cubehouse]

Summary

parksapi #77: dining.test.ts's "rolls a past-midnight close into the
next day" test fails under TZ=Pacific/Kiritimati (UTC+14), green under
UTC, America/New_York, Europe/Paris, Asia/Tokyo.

Root cause turned out to be a real production bug, not a test artifact.
Two call sites in disneylandparis.ts — the dining-hours block in
buildLiveData(), and the equivalent block in buildSchedules() — advance
a midnight-crossing close time via:

const nextDay = addDays(new Date(`${dateStr}T00:00:00`), 1);

That bare Date string parses in the host's local zone, not the park's.
On any host east of Paris, "add a day" can silently fail to cross the date
boundary before the result gets reformatted into Europe/Paris.

A third call site in the same file (the walkthrough-hours window check)
already carries the fix and an explicit warning comment about this exact
trap, landed under #63 ("Guard against the UTC-date-as-local-day trap
library-wide"). These two were simply missed by that sweep.

Fix

Route both remaining sites through shiftDateString() (already imported
in this file, already used at the walkthrough site) instead of the bare
new Date() + addDays + formatInTimezone roundtrip. It anchors at noon
UTC, so no offset or DST shift can push it across a date boundary.

Testing

• Added a TZ-parameterised regression test at each site (UTC,
  Pacific/Kiritimati, Pacific/Auckland, Asia/Tokyo,
  America/Los_Angeles) — the same process.env.TZ loop pattern already
  used for shiftDateString's own regression test in datetime.test.ts.
  Self-contained: catches a regression on npm test from any host, no
  external TZ override needed.
• Full suite (2047 tests) green under TZ=Pacific/Kiritimati,
  TZ=Pacific/Midway, and the default host TZ — swept the whole suite,
  not just DLP, per the issue's suggestion. No other host-TZ-dependent
  flakes found.
• tsc --noEmit and npm run build clean.

Note: "#77" above refers to the ThemeParks/programme tracking issue, not a
parksapi-repo issue — no Closes keyword used here since that issue lives
in a different repo and GitHub's auto-close only works within the same
repo. Tracked and closed manually on the programme board.

Test plan

• Full suite passes under three different TZ values
• Typecheck and build pass
• Confirmed the exact originally-reported failure now passes

🤖 Generated with Claude Code