read-api: pass request.signal into Sheet.query/queryFirst/queryAll for client-disconnect cancellation

gitsheets 1.0.5 shipped `AbortSignal` support on `Sheet.query` / `queryFirst` / `queryAll` (upstream #154). [`plans/read-api.md`](https://github.com/CodeForPhilly/codeforphilly-ng/blob/main/plans/read-api.md) shipped before this was available, so our read services don't currently honor cancellation.

## What

Thread `request.signal` (Fastify provides one when the client disconnects) into the `Sheet.query` calls in `apps/api/src/services/*` so a slow query for a disconnected client aborts at the next yield boundary instead of running to completion.

## Why

At civic scale we won't hit it often, but a `?q=…` over a large in-memory corpus could chew CPU after the user has navigated away. Free win for ~5 lines.

## How

Each service method needs an `AbortSignal` parameter threaded from the route:

```ts
fastify.get('/api/projects', async (request) => {
return projectService.list({ ...query, signal: request.raw.signal });
});
```

```ts
async list(opts: { signal?: AbortSignal, ...}) {
for await (const project of this.sheet.query({ signal: opts.signal })) {
// ...
}
}
```

Tests: a unit test that aborts mid-iteration and asserts the AbortError reason matches.

## Out of scope

- The FTS engine's `?q=…` path (better-sqlite3) doesn't expose an AbortSignal hook in its own API; cancellation there waits on a separate decision.

Đọc plans/read-api.md, sau đó kiểm tra các trình xử lý route và các phương thức service trong apps/api/src/services/*. Theo dõi các lệnh gọi hiện có đến Sheet.query, queryFirst và queryAll, đồng thời truyền request signal qua từng entry point bị ảnh hưởng. Thêm một unit test hủy trong khi lặp và xác minh lý do của AbortError.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.