Web redesign Phase 6/8: Room reservations (no borrow/return)

# Why?

**As a** user booking a room (not a physical item)
**I want** to reserve a room for a time window without any borrow/return step
**So that** the app supports room bookings, not just checkoutable inventory — rooms don't need to be "picked up" or "returned," just reserved.

# What?

Phase 6 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 2 (#334, overdue query) and Phase 4 (#336, resource detail UI) being in place to modify.

# Design decision (resolved during planning)

Rooms are modeled as `MainSchema.type: "item" | "room"` (new field on the existing schema) rather than a separate `RoomSchema`/table — this lets rooms reuse all existing resource/sub-item/`ScheduleSchema` machinery, minimizing new backend surface. Existing rows default to `type: "item"`.

Scope:
- Backend: add `type: "item" | "room"` to `MainSchema` (`ts-code/src/db/Schemas.ts`); thread it through `AddItem`, `GetItem`, `ListItems` and their `web/lib/api/*` wrappers/types. Existing-row backfill approach (one-time migration vs. read-time fallback treating missing `type` as `"item"`) to be decided during implementation — DynamoDB is schemaless so a read-time fallback is likely simpler and lower-risk.
- Frontend: resource creation/detail UI gains a type selector. For `type === "room"`:
- Hide Borrow/Return actions entirely.
- Exclude the resource from Phase 2's `ListOverdueItems` results (rooms are never "overdue").
- Reserve (including Phase 4's basket/multi-select reserve flow) remains the only available action.
- No new reservation logic needed — reuses all existing `ScheduleSchema`/`CreateReservation` machinery unchanged.
- **No new or modified reservation write path may skip existing double-booking protection** — room reservations must go through the same `ScheduleTable.create`/`validateDate` overlap check as item reservations; do not add a room-specific bypass.

# Testing

Per this repo's testing policy: unit tests for the `type` field threading through `AddItem`/`GetItem`/`ListItems` and the overdue-query exclusion; Jest/RTL for the conditional Borrow/Return UI hiding; Playwright e2e for reserving a room end-to-end (confirming no Borrow/Return UI appears and no overdue alert is ever generated for it).

# Additional context

Part of an 8-phase `web/` redesign series (#333-#337). Phase 7 and 8 are independent of this phase but build on the same resource/dashboard UI it modifies.

Comece examinando o `MainSchema` em `ts-code/src/db/Schemas.ts` para entender a estrutura existente. O trabalho envolve adicionar um campo `type`, modificar os API wrappers em `web/lib/api/*` e atualizar a frontend UI para ocultar condicionalmente as ações Borrow/Return. Os testes exigem unit tests para a lógica do novo campo, Jest/RTL para as alterações de UI e um teste e2e do Playwright para o room reservation flow. Garanta que nenhuma alteração contorne a validação existente de double-booking em `ScheduleTable.create`.

Escrita pelo modelo de indexação a partir do texto da issue.