Add printer_han (CJK) support and close SDK/docs gaps vs API v3

[tomsaas]

Summary

The official API docs (v3 export) document a new request-body field, printer_han,
required to print Chinese, Japanese or Korean text on both print endpoints
(printers.createPrintJob and devices.usb.createPrintJob). Without it, the server
composes the ticket in single-byte mode and silently replaces every CJK character with
? before the job reaches the printer — no error is raised.

• Added printer_han ("cn" | "kr" | "jp" | "1") to CreatePrintJobRequest and
  CreateUsbPrintJobRequest, exported as PrinterHan / PrinterHanScript.
• New reference page docs/receipt-layout/asian-characters.md
  and two runnable examples (examples/receipt-asian-characters.ts,
  examples/device-rpi-usb-print-asian.ts).
• Endpoint docs, text-layout-tags.md, docs/README.md and the root README.md updated
  to reference it.

While diffing the full doc export (340 articles) against the repo, I also found and fixed:

• CreatePrintJobResponse.request_timestamp is now optional. It's returned by the API
  but isn't part of the documented v3 response contract — this is the one type change that
  could affect existing consumers who read it without an optional check.
• printer_status documented as an activation flag ("1"/"0"), not a live
  connectivity indicator — the repo previously just said "numeric status flag".
• JSDoc added across src/types/*.ts for fields that had no explanation in code
  (last_ping, notification_url, printer_graphic_mode, …).
• New docs/getting-started/errors.md (status codes by endpoint, ExpedyError vs
  ExpedyApiError) and docs/concepts/delivery-and-idempotency.md (a 200 means
  accepted/queued, not printed; no de-duplication).

Additional groundwork requested alongside the CJK fix

• openapi.yaml — OpenAPI 3.1 description of all 16 operations, printer_han as an
  enum, matches src/types/**. Linted clean with @redocly/cli.
• Tests + CI — test/client.test.mjs (Node's built-in test runner, no dependency,
  mocks fetch via the config the client already accepts) and .github/workflows/ci.yml
  (Node 18/20/22: typecheck, build, typecheck examples, test). publish.yml is untouched.
• Agent/LLM-facing files — AGENTS.md, llms.txt.
• Repo hygiene — CONTRIBUTING.md, SECURITY.md, CHANGELOG.md (retro-filled from
  git history), issue templates, PR template.
• docs/integrations.md — indexes the ~140 no-code/e-commerce/delivery platforms from
  the doc export (Zapier, Shopify, WooCommerce, Uber Eats, n8n, …), each linking to
  docs.expedy.io, with a short "SDK vs. no-code" decision note.

Bumps 1.0.2 → 1.1.0 (package.json + package-lock.json).

docs/integrations.md links — verified against the site's sitemap

The links initially missed the /en/ locale segment. The user provided the actual
docs.expedy.io sitemap, which confirms the canonical pattern is
docs.expedy.io/en/<category>/<subcategory>/<slug> (e.g.
docs.expedy.io/en/expedy-print/api-print-v2/create-a-print-job). All 140 links in
docs/integrations.md, plus the cross-reference in asian-characters.md, have been
corrected to include it.

Test plan

• npm run typecheck && npm run build && npm run typecheck:examples — pass
• npm test (node --test) — 12/12 pass, including a CJK round-trip test and tests
  confirming printer_han reaches the JSON body on both endpoints
• npx @redocly/cli lint openapi.yaml — valid
• Reviewed the full diff for real credentials/UIDs/internal URLs (public repo) — only
  placeholder values consistent with the existing repo conventions
• docs/integrations.md link pattern verified against the site's sitemap

Suggested repo metadata (not something I can set via the tools available to me)

• Topics: thermal-printer, receipt-printer, escpos, cloud-printing,
  pos-printer, raspberry-pi, label-printer, print-api, nodejs, typescript,
  sdk, google-cloud-print-alternative, cjk
• About → website: https://docs.expedy.io
• Publishing a GitHub Release v1.1.0 off this PR is what triggers publish.yml
  (OIDC trusted publishing) and gives the version its own indexed page.

🤖 Generated with Claude Code