fix(settings): the timezone field could store a value that breaks every report

[goetchstone]

The America/New_York default is fine as a default. What wasn't fine is how it could be changed.

The admin Localization form is free text, and the API validated it as "a non-empty string" — so "Eastern" or "America/Nowhere" saved successfully. Nothing rejected it and nothing fell back: getAppSettings only guarded empty (row.timezone?.trim() || DEFAULT), so a non-empty invalid value went straight to Intl.DateTimeFormat, which throws a RangeError.

That's the same string salesDaily, generateSalesJournal and computeDailyReconciliation all resolve their day against. One typo in an admin form broke all three money paths at once — and the first symptom would have been tomorrow's empty report.

Three layers, each catching what the others can't

layer	what it does
GUI	The field is a picker, not free text. Intl.supportedValuesOf omits "UTC" (it lists Etc/UTC), so UTC is prepended explicitly — it's the neutral answer and shouldn't need hunting for. An already-stored value the list doesn't contain still renders, marked.
Write	The API rejects a zone this runtime can't format with, naming the value, so an operator learns immediately rather than tomorrow.
Read	getAppSettings falls back to the default on an invalid stored value and logs it. Rows written before this guard — or by any other path — can't keep every report broken. Falling back rather than throwing is this function's existing contract: reads never fail on bad settings.

Why a probe, not an allow-list

isValidTimeZone is a try/catch against Intl rather than a membership test against supportedValuesOf. The test pins the reason: that list omits "UTC", so an allow-list would reject the most obviously valid answer.

I got the boundary wrong first

Worth recording. Intl is looser than an IANA-only reading suggests:

• Zone names match case-insensitively — america/new_york is valid
• Legacy aliases resolve — EST, GMT, US/Eastern

My first draft asserted, in the test and in a code comment, that America/New_york (lowercase y) was "the classic typo" that breaks. It isn't. The test caught it, and both the comment and the assertion are corrected.

What genuinely fails: a colloquial name (Eastern), a non-existent zone (America/Nowhere), and surrounding whitespace — which is why callers trim before validating. The guard now inherits Intl's real boundary instead of being stricter than the code it protects, and the test pins both directions: every accepted value is safe to hand the date helpers, every rejected one really does throw.

Still open

timezone is GUI- and API-configurable but not expressible in a config preset — so "via code" isn't covered for this field yet. That's a separate piece of work (a settings preset kind), not folded in here.

Verification

• next build — exit 0 (a client component changed; this is the check tsc can't do)
• tsc --noEmit — 0
• jest --selectProjects unit — 212 suites, 3,299 tests, 41 of them new
• eslint 0 errors (1 pre-existing warning, untouched), prettier clean

🤖 Generated with Claude Code