feat: support a custom id field per resource

[Jia-ben00]

What

Adds an --id option to use a different field than id as the unique identifier of items:

• --id post_id uses post_id as the id field for all resources
• --id ids.json uses a per-resource mapping from a JSON file, e.g.

{
  "posts": "post_id",
  "comments": "comment_id"
}

The same option is available through the JavaScript API: createApp(db, { id }).

Why

This has been requested since 2016 in #279 (50 comments). Today every resource is forced to use the id field, which makes json-server unusable with databases that use other primary key names.

How it works

• Service and NormalizedAdapter both accept an IdOption (string global field, or Record<resource, field> per-resource mapping)
• All CRUD operations (findById, create, updateById, patchById, destroyById) and id normalization (numeric to string, auto-generation) use the resource's id field
• Default behavior is unchanged when --id is not passed

Tests

• src/service.test.ts: CRUD against per-resource and global custom id fields
• src/app.test.ts: HTTP integration (GET/POST/DELETE) with a custom id field
• src/adapters/normalized-adapter.test.ts: id normalization with custom fields, no default id injection

All 141 tests pass, tsc --noEmit and oxlint are clean.