feat(clio): support regional OAuth hosts and credentials

[roboli]

Why

Clio runs each region (US, EU, CA, AU) as a separate instance. Per Clio's docs, each region needs its own developer application (different client ID/secret), and "a token issued in one region is not valid against another region's API" (Regions, Applications).

The module hardcoded OAuth to app.clio.com with the US app's credentials and ignored the region sent at authorization time, so non-US accounts couldn't connect. Quo is adding a "Clio (Canada)" app that sends { entityType: "clio", data: { code, region: "ca" } }.

What changed

• api.ts: one host per region; setRegion() now switches the API base URL, OAuth authorize/token URLs and client credentials together. The constructor goes through setRegion(), so an entity persisted with region: "ca" loads (and refreshes tokens) against ca.app.clio.com.
• definition.ts: getToken honours params.region before exchanging the code. New CLIO_{EU,CA,AU}_CLIENT_ID / CLIO_{EU,CA,AU}_CLIENT_SECRET env vars, passed to the Api as regional_credentials. A region without its own credentials falls back to CLIO_CLIENT_ID/CLIO_CLIENT_SECRET.
• A persisted region of null or '' is treated as us (core's get() only defaults on undefined).
• First unit tests for the package (test/regions.test.ts, 10 tests): US default, persisted region, credential fallback, switching back to US, invalid region, code exchange with/without region, token refresh in the persisted region. The 4 region tests fail against the previous code.

Compatibility

US behaviour is unchanged: same URLs, same CLIO_CLIENT_ID/SECRET, no new env vars required. Checked the consuming app's data read-only: all Clio entities in dev (4) and prod (171) are persisted with region: "us".

Testing

• npx tsc -p tsconfig.json and npx vitest run in packages/v1-ready/clio (10/10).
• Live test against a Clio Canada trial account will run against this PR's canary build. Note: Clio doesn't document the Manage OAuth host for non-US regions explicitly; ca.app.clio.com/oauth/* follows from the API host and will be confirmed by that test.

🤖 Generated with Claude Code

📦 Published PR as canary version: Canary Versions

✨ Test out this PR locally via:

npm install @friggframework/api-module-clio@1.1.0-canary.103.daa1c68.0
# or 
yarn add @friggframework/api-module-clio@1.1.0-canary.103.daa1c68.0

[roboli]

Live test against a Clio Canada account

Tested 1.1.0-canary.103.daa1c68.0 from a consuming Frigg app (local stack), against a Clio Manage trial account hosted at ca.app.clio.com, with a developer app registered in that account's region.

Check	Result
Authorize with { code, region: "ca" }: code exchanged at https://ca.app.clio.com/oauth/token using the CA app's credentials	✅ entity persisted with region: "ca"
who_am_i / API calls against https://ca.app.clio.com/api/v4	✅
Webhook + custom action created in the CA instance	✅
Contacts read from the CA instance	✅
Inbound and outbound call communications written to the CA instance	✅
Forced token refresh (access token invalidated): refresh sent to the CA token endpoint, request retried	✅ new token persisted, call logged

This also confirms the OAuth host for Clio Manage in Canada is ca.app.clio.com/oauth/*. The docs only list regional OAuth hosts for Clio Platform.

Credential probes with a dummy code back up the per-region setup: the CA app's credentials return invalid_grant (accepted) at ca.app.clio.com and invalid_client at app.clio.com, and a US app's credentials do the reverse. So both the token host and the client credentials have to follow the region, which is what this PR does.

US behaviour unchanged: default region, same URLs, same CLIO_CLIENT_ID/CLIO_CLIENT_SECRET.

🤖 Generated with Claude Code