fix(carddav): honour fetch override in makeAddressBook

[PhilflowIO]

Fixes the red pnpm typecheck on master.

The defect

makeAddressBook was the only function in addressBook.ts that neither accepted a fetch override nor forwarded one to davRequest. I scanned every exported function that takes fetchOptions — it and the six todo functions were the only ones missing fetch?: typeof fetch, and the todo family is untouched here (see follow-ups).

Its structural twin makeCalendar does both: same params, same davRequest call, one MKCALENDAR vs MKCOL. And davRequest has always supported it — const requestFetch = fetchOverride ?? fetch;.

Two call sites were affected, and they failed differently:

• createDAVClient (client.ts:267) has passed fetch: fetchOverride to it since the upstream sync. That was the TS2353 error. At runtime the extra property was simply dropped on the floor.
• DAVClient.makeAddressBook (client.ts:694) never passed it at all — no type error, just silence. The class stores this.fetchOverride and forwards it in 28 other methods; this one was skipped.

Fixing only the type would have left the class path still broken, so both are fixed. No cast, no ts-ignore — makeAddressBook now matches makeCalendar exactly.

Runtime behaviour change

The override goes from dead to live for makeAddressBook. Anyone who configures a custom fetch and then creates an address book will see their fetch used where previously the MKCOL went out through the module-level default (native globalThis.fetch, else cross-fetch).

Concretely, for a consumer on KaiOS with mozSystem, or a Cloudflare Worker, or any environment where the default fetch cannot issue the request: client.makeAddressBook(...) previously bypassed their fetch and the MKCOL typically failed on CORS or privilege. It now succeeds. Anyone not passing a custom fetch is unaffected — fetchOverride is undefined and davRequest falls back exactly as before, which the second unit test pins down.

Verification

Before, on d411d78:

$ pnpm typecheck
> tsc --noEmit
src/client.ts(267,5): error TS2353: Object literal may only specify known properties, and 'fetch' does not exist in type 'Partial<{ url: string; props: ElementCompact; depth?: DAVDepth | undefined; headers?: Record<string, string> | undefined; headersToExclude?: string[] | undefined; fetchOptions?: RequestInit | undefined; }>'.
 ELIFECYCLE  Command failed with exit code 2.
EXIT=2

After:

$ pnpm typecheck
> tsc --noEmit
EXIT=0

$ pnpm test
Test Suites: 9 passed, 9 total
Tests:       32 passed, 32 total

Tests

Four, in the two existing unit suites — no new harness invented. Each was confirmed to fail when its half of the fix is reverted:

• addressBook.test.ts mocks ../../request (the file's existing pattern) and asserts davRequest receives the override, and receives undefined when none is passed.
• client.test.ts extends the existing "DAVClient fetch override" describe, driving a jest.fn() fetch through both DAVClient and createDAVClient and asserting it was actually called.

Reverting the addressBook.ts threading fails the first pair; reverting the this.fetchOverride wiring fails the DAVClient test while the createDAVClient test still passes — the two halves are independently guarded.

The dist/ diff is generated, and small this time (~64 lines): the repo's pre-commit hook rebuilt and staged it. CI verifies it against a fresh build.

Not in this PR

• The whole todo family has the same gap. todoQuery, todoMultiGet, fetchTodos, createTodo, updateTodo, deleteTodo all lack fetch?: typeof fetch, and none of the six DAVClient methods pass this.fetchOverride. It is not a type error only because client.ts never tries to pass it, so it is silent rather than red. That is a six-function feature change, not a typecheck fix.
• pnpm lint is red on master — 10 remaining prettier-only errors in client.ts, index.ts, todo.ts and addressBook.ts, all auto-fixable with pnpm lint --fix. All pre-existing: I verified the addressBook.ts one is present at line 346 on pristine master and merely shifted to 355 by this diff. It went 11 → 10 only because one sat on the line I rewrote. Untouched otherwise to keep this PR single-purpose. It stays red unnoticed because ci.yml never runs (below) and release.yml has the lint step commented out.
• .husky/pre-commit uses the husky v8 preamble; prints DEPRECATED on every commit, will fail on husky v10.
• ci.yml only triggers on PRs to main while the default branch is master, so typecheck/lint/test never actually run in CI.