fix: null-safe ApiError + jittered retry backoff for getAllBatch ECONNRESET (v1.3.0)

[alphahlee]

Problem

getAllBatch / getAllAssetsBatch crashed with Cannot read properties of undefined (reading 'status') when a page fetch hit a network error (e.g. ECONNRESET): the catch handler passed e.response (undefined for a network error) into throwResponseError, whose ApiError getters then dereferenced this.resp.status. Observed net-failing udst/udstsso assets on deployed connector nightlies.

Changes (single commit, rebased onto master)

• famis_client.ts getAllBatch catch: rethrow the real error when there is no HTTP response, instead of fabricating an ApiError from undefined.
• errors.ts null-safe isAuthorizationError / toString getters (this.resp?.…) so a response-less ApiError can't throw.
• axios-retry: retries 2 → 6 (via a RETRIES const referenced by the onRetry log too) with jittered exponential backoff (base 1/2/4/8/16/30s + up to 25% jitter) so a transient reset has time to clear; jitter de-synchronizes concurrent getAllBatch pages (no thundering-herd). The ECONNABORTED (timeout) one-retry cap is unchanged.
• onRetry logging ([facility360] retry N/6 …) so absorbed resets are visible even with debug off.
• Add CHANGELOG.md (Keep a Changelog format) with the 1.3.0 entry + a 1.2.0 backfill.
• Bump to 1.3.0 — not a new API (no signature change); the minor bump signals a notable behavior change (the retry policy affects every autoRetry consumer's failure latency) rather than a silent patch.

Explicitly NOT included

No { pageSize, maxConcurrent } opts and no per-fetch getAllBatch log line — those were local-testing scaffolding; the connector never uses the opts and signatures stay identical to master. (Corrects the earlier draft of this description, which mentioned them.)

Compatibility

No signature/API change. The only change reaching every autoRetry consumer is the retry policy — a failure-latency change on a genuinely down endpoint (~6ms → up to ~61s before giving up), not a correctness change. retryCondition still limits retries to network/idempotent errors + one retry on timeout (no retry-storm on 4xx). Note validateStatus: () => true is unchanged, so transient FAMIS 5xx are still surfaced via throwResponseError (not axios-retried) — the retry policy targets network errors/timeouts, which is the ECONNRESET case here. The request_timeout retry test was updated for the new count using fake timers (no real wall-clock cost).

Validation

Full local-connector fleet nightly (2026-07-10): 0 assets-loader failures across 1,920 loader runs; udst/udstsso (241k each) completed. 0 ECONNRESETs fired locally — the reset appears specific to the Cloud Run → FAMIS egress path, so the retry-absorbs-a-reset path should be confirmed post-deploy via the [facility360] retry log lines. All 94 SDK unit tests pass.

🤖 Generated with Claude Code