fix(packaging): align the SQLAlchemy dependency range with the documented support matrix #774

Problem

The declared dependency range and the documented support matrix disagree about SQLAlchemy 2.2:

• pyproject.toml:34 and :49 declare sqlalchemy>=2.0,<2.3 (and sqlalchemy[asyncio]>=2.0,<2.3).
• docs/SUPPORT_MATRIX.md:15 lists ≥ 2.2 | ❌ Not supported | Code uses private SA internals.
• README.md:218 says "SQLAlchemy 2.0–2.1 only — pinned to <2.3".

SQLAlchemy 2.2 is not released yet (latest on PyPI: 2.1.4). As soon as it is, pip install sqlalchemy-cubrid will resolve to 2.2 even though the project documents it as unsupported and the full compatibility matrix has never run against it. Earlier releases added forward-compat shims for 2.2 (v1.5.0, v1.6.0) and a --pre canary job exists, so "forward-tested" and "supported" are currently conflated.

Decision needed (maintainer)

Pick one supported range and make every declaration agree:

1. Cap at <2.2 — the dependency matches the documented support (2.0–2.1). Lift the cap in a release that has run the full matrix against 2.2.
2. Keep <2.3 — then 2.2 must be documented as supported, which requires the full compatibility matrix (not only the --pre canary) to pass against 2.2 before 2.2 is released to users.

Recommendation: option 1. It is the conservative choice while 2.2 is unreleased and unverified, and the canary job keeps forward-testing it.

Scope

• Make pyproject.toml (both dependency lines), docs/SUPPORT_MATRIX.md (EN/KO), README.md and translations, docs/llms*.txt, and any CI matrix/packaging-smoke-test constraints state the same range.
• Add a repo test that fails if the dependency upper bound and the documented supported range diverge.
• CHANGELOG entry under the appropriate section; release classification per RELEASE_POLICY.md (a cap change is a packaging metadata change).

Out of scope

• Proactive development for SQLAlchemy 2.2+ support.
• Changes to the --pre canary job beyond keeping it.
• Bundling this into the pending 1.10.1 release PR (chore(main): release 1.11.0 #770) unless the maintainer decides so.

Acceptance criteria

• One SQLAlchemy range is stated identically in package metadata and all user-facing docs.
• A test guards the agreement.
• The chosen option is recorded in the issue before implementation.