Web redesign Phase 8/8: Extend reservation (in-place, with strengthened overlap check)

# Why?

**As a** user whose meeting/project ran long
**I want** to extend an existing reservation's end time instead of deleting it and creating a new one
**So that** I don't lose the reservation's identity/history and don't risk a race where someone else books the slot between my cancel and recreate.

# What?

Phase 8 of an 8-phase redesign of `web/` modeled after our internal Retool RMS app (`https://a2nseattle.retool.com/p/rms-alpha/main`). Depends on Phase 3 (#335, Scheduled/Upcoming dashboard view).

# Design decision (resolved during planning)

Extend-in-place (update `endTime` on the existing `ScheduleTable` row) rather than cancel-and-recreate — preserves the reservation's id/identity and avoids the two-call race window a cancel+recreate approach would have.

Scope:
- Backend: new `ExtendReservation` API (`ts-code/src/api/ExtendReservation.ts` + handler + route), following the standard new-API recipe used throughout this repo (`ts-code/src/handlers/api/.ts` thin wrapper + `amplify/functions//resource.ts` + route registration in `amplify/api/resource.ts`). Updates `endTime` on an existing `ScheduleTable` row in place, reusing `CreateReservation`'s overlap-validation logic (`ScheduleTable.create`'s `validateDate` check, `ts-code/src/db/ScheduleTable.ts`) against the *other* schedules for the same item(s) — excluding the row being extended from that check.
- **Known gap to close, not inherit**: `validateDate` (`ts-code/src/db/ScheduleTable.ts:232-239`) only checks whether either new endpoint falls inside the *old* range — it misses the case where the new (extended) range fully *contains* an existing reservation. `ExtendReservation` must not just reuse `validateDate` as-is against the extended range without confirming this gap doesn't let an extension silently swallow another reservation that falls entirely within the new window. Tighten or supplement the check as part of this phase.
- Frontend: an "Extend" action on the dashboard's Scheduled/Upcoming view (Phase 3) and/or resource detail page, prompting for a new end time.

# Testing

Per this repo's testing policy: unit tests for `ExtendReservation` covering (a) a valid extension into open time, (b) rejection when the extended range overlaps another reservation at either endpoint, and (c) rejection when the extended range fully contains another reservation (the gap above) — this last case must be tested explicitly, not assumed covered by existing `validateDate` tests. Jest/RTL for the Extend UI; Playwright e2e for the extend flow.

# Additional context

Part of an 8-phase `web/` redesign series (#333-#339), the final phase.