v1.4.1 — v2 timezone, casing & rate-limit corrections

Corrections release. Six places where the v2 references described the API
inaccurately, all verified against the deployed qore/api and the live public
docs.

Read these two if you already integrate v2

• ⚠️ updatedAfter is read in Europe/Rome, not UTC. Polling incrementally
  in UTC does not raise an error — it silently skips shipments in the offset
  window. If you built an incremental sync on UTC timestamps, check it.
• ⚠️ /v2/sandbox responses are camelCase since qore/api 2.21.10 (live in
  production since 2026-09-03). They used to come back in snake_case while
  accepting camelCase on the way in. Breaking if you parse
  string_value / created_at — rename to stringValue / createdAt.

Also fixed

• v2 is not uniformly UTC and never emits a literal Z. parcels and
  orders use ATOM with an explicit +00:00; shipment tracking (statusDate,
  statusUpdatedAt, history[].date) and sandbox return "Y-m-d H:i:s" with
  no offset, in Europe/Rome. Moving tracking to real UTC is a planned
  breaking change, not a done one.
• orders, shipments, labels and couriers are in the public spec. They
  were marked "not yet published" — the Swagger snapshot had simply gone stale at
  2.14.0. They are published, just not written up in depth in this pack.
• Authentication: the field is apiKey, and the public docs now show it
  correctly. A wrong field name returns 422 (apiKey should not be blank),
  not 400; 400 means an absent or malformed body. 429 on the token endpoint
  is documented too.
• The v2 rate limit is 300 capacity, refill 150/min (since qore/api
  v2.20.0). The pack still documented 120 capacity and 2/sec, which is the
  separate v1.x bucket.
• The published spec's info.version does not identify the contracts inside
  it. It is a hand-dumped snapshot whose label reflects whenever the dump ran.
  Use it to spot a badly stale spec, never to decide whether a feature is
  present — read the schemas, or ask the live GET /v2/version.

Full detail in CHANGELOG.md.