Hardcoded client-side caps duplicate server constraints (drift risk)

[justin-layerv]

Context

src/client.ts hardcodes several client-side caps that mirror server constraints:

• MAX_TARGET_URL = 2048
• MAX_MAX_SESSIONS = 1000
• MAX_TAGS = 10
• MAX_TAG_LENGTH = 50
• MAX_LABEL / MAX_DESCRIPTION (similar)

If the API ever raises any of these caps (e.g., an enterprise plan allows max_sessions: 2000), the SDK will reject valid inputs with no override path.

Surfaced in cr review on PR #14: #14 (comment)... (item #3).

Options to consider

1. CI diff against openapi.yaml — script that fails CI when an OpenAPI numeric constraint diverges from the matching constant. Keeps the hardcoded values but turns drift into a build failure.
2. Constructor override — let callers loosen the cap at new QURLClient({...}) time (maxTags, maxTargetUrl, etc.). Server still validates authoritatively; client cap becomes a soft fail-fast.
3. Drop the client-side cap entirely for fields where the server already returns a clean ValidationError — accept the round-trip cost in exchange for zero drift.

Acceptance

Pick one of the above (or another approach) and apply it consistently across MAX_* constants. Document the chosen rationale in a code comment on the constants block.