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.

Lisez plans/read-api.md, puis examinez les gestionnaires de routes et les méthodes de service sous apps/api/src/services/*. Suivez les appels existants à Sheet.query, queryFirst et queryAll, puis faites transiter le signal de la requête par chaque point d’entrée concerné. Ajoutez un test unitaire qui interrompt l’itération et vérifie la raison de AbortError.

Rédigé par le modèle d'indexation à partir du texte de l'issue.