feat: add the schedule resolution engine with its test table

This is the business core, written before any UI as the spec requires.
It is pure: no I/O, no database, no clock of its own. Everything arrives
in a ScheduleContext, so every rule below is exhaustively testable.

The engine works on civil (wall-clock) values rather than instants. A
slot that runs 10:00-18:30 runs 10:00-18:30 on the nights the clocks
change too, and day arithmetic goes through UTC, which has no daylight
saving. That turns the March and October switches from edge cases into
non-events, and the tests pin both of them.

Priority order, highest first: a dated exception, a vacation period, a
public holiday the shop closes for, the reference week, then closed.
Exceptions are badged by their stated reason rather than by who created
them, so a holiday imported by the sync shows as a holiday in the UI.

The search for the next opening is bounded to fourteen days. A shop that
is closed forever must not make the server spin; past the horizon the
screen simply says nothing about reopening. Both the never-open week and
the beyond-the-horizon reopening are covered.

"Soon" is strictly under thirty minutes, so a change exactly half an
hour away still reads as plain OPEN or CLOSED.

55 tests; lib/schedule sits at 97% statements and 93% branches against
an 85% floor. The thresholds were verified to actually fail the build
before being committed.

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

.github/workflows/ci.yml

@@ -24,5 +24,5 @@ jobs:
       - run: npx prisma generate
       - run: npm run lint
       - run: npm run typecheck
-      - run: npm run test
+      - run: npm run coverage
       - run: npm run build