chore(deps): relax authlib pin to >=1.6.5,<2

[kannwism]

Why

A customer asked whether we can relax the exact authlib==1.6.5 pin in the SDK (it forces dependency conflicts in their environment).

Investigation

The exact pin is not deliberate:

• authlib was added in fix: RAPID-4589 credentials lost after a prolonged period of time #228 (credentials lost after a prolonged period — the OAuth2 refresh-token client, authlib.integrations.httpx_client) as a flexible ^1.5.1.
• It only became the hard ==1.6.5 in the uv migration (feat: migrate to uv #407), which froze the then-resolved version. There is no rationale comment and no compatibility guard requiring an exact version.

An exact pin is especially harmful in a published SDK — it propagates a version conflict to every downstream consumer.

Change

Relax to authlib>=1.6.5,<2 (matches the original caret intent, floored at the currently-tested version).

Verification

• uv lock resolves cleanly.
• Forced upgrade to the latest 1.x (1.7.2) imports the OAuth2Client / OAuthError symbols the SDK actually uses, under the existing httpx>=0.28.1,<0.29 constraint. authlib does not cap httpx.

🔗 Session: https://t-28283203d35cde.poseidon.rapidata.internal/

[claude]

Reviewed the diff. This is a small, well-scoped dependency change and I don't see any correctness issues.

Code quality / rationale

• The PR description does a good job digging into the history of the pin (added as ^1.5.1 in fix: RAPID-4589 credentials lost after a prolonged period of time #228, accidentally frozen to ==1.6.5 during the uv migration in feat: migrate to uv #407). Relaxing to >=1.6.5,<2 is a reasonable middle ground: it removes the incidental exact pin while still capping at the next major to guard against breaking changes.
• The only two usages of authlib in the codebase are OAuth2Client and OAuthError from authlib.integrations.httpx_client (src/rapidata/api_client/rest.py, src/rapidata/service/openapi_service.py). Both symbols are stable in the authlib public API, so the relaxed range looks safe for actual usage.

Dependency/lockfile considerations

• authlib 1.7.x pulls in a new transitive dependency, joserfc, which wasn't previously in the lock file. Worth confirming there's no license/security concern with adding this new transitive dep (it's BSD-licensed and authlib's own dependency, so this is likely fine, just flagging since it's a new package entering the dependency tree).
• The uv.lock diff also includes unrelated churn to ipython/ipython-pygments-lexers/exceptiongroup marker conditions (dropping python_full_version markers). This is presumably just uv lock normalizing resolution markers as a side effect of re-resolving, not something intentionally changed by this PR — but worth double-checking it doesn't silently change which packages get installed on Python 3.10 vs 3.11+ environments (these are dev-only deps per the extras, so risk is low, but still worth a sanity check that uv sync --group dev behaves the same across supported Python versions).

Security

• No security concerns with widening the range itself — >=1.6.5,<2 still excludes any known-vulnerable pre-1.6.5 releases and caps at a major version boundary, which is the right way to relax a pin in a published SDK.

Test coverage

• No behavioral code changes, so no new tests are needed. The verification described (forced upgrade to 1.7.2, uv lock resolves cleanly, symbols import fine under the existing httpx constraint) is appropriate for a dependency-range-only change.

Overall: looks good to merge. Only worth a quick look at the incidental uv.lock marker churn for the dev dependencies before merging, just to confirm it's expected from the re-resolve and not masking something else.