Honor the document's update mode (PATCH vs PUT) for background writes #5

Problem

Background update writes are always sent as PUT, hardcoded in attemptWrite (src/client/client.ts):

if (write.type === 'update') {
  const updated = await requestJson(itemUrl(route, write.id), {
    method: 'PUT',
    ...
  });
}

Some APIs do not accept PUT on a resource and require a partial PATCH. The GitHub Issues API is the motivating case: updating an issue (including flipping its state between open/closed) is PATCH /repos/{owner}/{repo}/issues/{issue_number} — GitHub does not offer a PUT for issues, so a PUT write fails.

Reflector's CRUD-causality overlays already declare the intended semantics per operation, e.g.:

x-crud:
  action: update
  mode: patch          # vs. replace
  patchFormat: custom

but syncables ignores mode and always issues PUT.

Request

When applying a queued update, choose the HTTP method from the resolved CRUD metadata for the resource:

• mode: replace → PUT (current behaviour, the default);
• mode: patch → PATCH, sending the merged/partial body syncables already computes.

Ideally derive this from the document (the x-crud update mode / which of put/patch the path item declares) rather than a new client option, so it stays document-driven like the rest of the engine.

Why it matters here

Reflector needs to reflect an issue's open/closed state from one GitHub tracker to another (localthought/reflector). That reflection is an update on the mapped target issue; with PUT hardcoded it can never succeed against GitHub.

Acceptance

• A resource whose document declares a patch-mode update issues PATCH; a replace-mode update still issues PUT.
• Test covering both against the mock server (or a fetch stand-in that asserts the method).