Web redesign Phase 2/8: Backend read APIs (owned/borrowed items, overdue, upcoming reservations)

# Why?

**As a** frontend developer building the Phase 3-8 UI (dashboard, alerts, room reservations)
**I want** backend read APIs for "items I own," "items I'm borrowing," "overdue items," and "upcoming/unclaimed reservations"
**So that** later phases have real data to render instead of reconstructing this client-side from unfiltered scans.

# What?

Phase 2 of an 8-phase redesign of `web/` modeled after our internal Retool RMS app (`https://a2nseattle.retool.com/p/rms-alpha/main`). **Backend-only, no frontend** — mirrors the shape of GH-306 PR 1/4 (routes-only, no UI).

Add new business-logic classes following the existing recipe (`ts-code/src/api/.ts` + `ts-code/src/handlers/api/.ts` + `amplify/functions//resource.ts` + route registration in `amplify/api/resource.ts`):

- **`ListMyOwnedItems`** — filter `MainSchema` by `owner === `. Exact "owned by me" semantics (does `MainSchema.owner` always hold an email, or sometimes a location/team name?) to be confirmed during implementation by reading current data via `ts-code/__tests__/integration`.
- **`ListMyBorrowedItems`** — filter `ItemsSchema` by `borrower === `, same Scan+FilterExpression shape as `ScheduleTable.listByBorrower` (`ts-code/src/db/ScheduleTable.ts`).
- **`ListOverdueItems`** — items where `borrower` is set and current time exceeds the relevant schedule's `endTime`. Needs to cross-reference `ScheduleTable` since `ItemsSchema` alone has no due-date field. Exact "overdue" definition (which schedule counts, what if there's no matching schedule for a currently-borrowed item) needs to be pinned down during implementation.
- **`ListUpcomingReservations`** — `ScheduleTable` entries for the current user where `startTime` is in the future, or has passed without a corresponding borrow ("hasn't been picked up yet").

# Constraints

- Follow the existing 1:1 test-mirror convention: `ts-code/__tests__/unit/api/.test.ts` and `ts-code/__tests__/unit/handlers/api/.test.ts` for each new class/handler.
- No `ampx sandbox` pre-verification (per this repo's Deploy verification policy) — merge once CI is green (build + `test:unit` + 80% coverage + CodeFactor) and verify via `backend-cd.yml`'s post-merge `test:integ` run against `alpha`.
- Don't close this issue until the post-merge integration test has actually passed against the real `alpha` stack.

# Additional context

Part of an 8-phase `web/` redesign series:
- Phase 1: design system + restyle (no new APIs)
- **Phase 2 (this issue): backend read APIs**
- Phase 3: dashboard page — depends on this issue's routes
- Phase 4: resources list + basket-style multi-select borrow/reserve — depends on this issue for the borrow-via-reservation wrapper
- Phase 5: return flow + batches view
- Phase 6: room reservations (no borrow/return) — depends on this issue's overdue query to exclude rooms
- Phase 7: batched return-by-reservation with condition notes
- Phase 8: extend reservation

首先檢查 `ts-code/src/api/` 和 `ts-code/src/handlers/api/` 中現有的 API 模式。檢視 `MainSchema` 和 `ItemsSchema` 以了解資料模型，並查看 `ts-code/src/db/ScheduleTable.ts` 中的 `listByBorrower` 方法。在 `ts-code/__tests__/unit/api/` 和 `ts-code/__tests__/unit/handlers/api/` 中為每個新類別撰寫單元測試。所有四個新 API 都已實作、單元測試通過，且針對 `alpha` 環境的 post-merge 整合測試成功執行後，工作即告完成。

由索引模型根據 Issue 內容生成。