Allow a resource's identity field to be configured (not hardcoded to id) #4

Problem

The client treats the record property literally named id as the resource's identity everywhere:

• create reconciliation — attemptWrite reads String(created['id']) from the POST response and moves the local record onto it (src/client/client.ts);
• storage keys — sync() / performSync store items under String(item['id']), and create/update key off data['id'];
• item URL — itemUrl(route, id) substitutes that same value into the item path's {param}.

This is fine for APIs whose resources are addressed by a field called id, but it breaks for APIs where the URL identity is a different field. The motivating case is the GitHub Issues API: an issue's create/GET/PATCH response carries both a global id (database id) and a per-repo number, and the item URL is /repos/{owner}/{repo}/issues/{issue_number} — keyed on number, not id. Today syncables would substitute the global id into {issue_number} and produce the wrong URL, and would key local storage on the global id rather than the addressable one.

Reflector already models this distinction — its ResourceModel derives an idField from the CRUD-causality overlay's identity binding (e.g. bindings: { issue_number: { field: number } }) — but there is no way to push that through to the syncables client, which always assumes id.

Request

Let the identity field be declared per resource (e.g. from the OpenAPI document's identity binding / x-crud, defaulting to id for backward compatibility) and use it consistently for:

1. storage keys during sync() and in list/get/create/update/remove;
2. the value read back from a create response to reconcile the client-generated id onto the server-assigned one;
3. the value substituted into the item URL's path parameter.

Why it matters here

Reflector wants to point its generic, document-derived sync flow at GitHub issue trackers and reflect issues between them (localthought/reflector). Issues are addressed by number; without a configurable identity field, reads land under the wrong key and every issue-level write (e.g. reflecting an open/closed state change) targets the wrong URL.

Acceptance

• Identity field is configurable per resource, defaulting to id.
• A fixture/test where the collection item path param differs from id (e.g. number) round-trips create → reconcile → update against the correct URL and storage key.
• Existing id-keyed behaviour unchanged.