build: switch the build backend from hatchling to uv_build

[sebartyr]

The project already uses uv for environments, dependencies, building and publishing. uv_build removes the one remaining build-time tool and is version-aligned with uv itself (both 0.12.5 here).

What it needs

Two settings must be explicit, and one of them prevents a silent regression:

• module-name = "clever_cloud" — the distribution is clevercloud-sdk but the module is clever_cloud, which uv_build cannot derive from the project name. Without it the build fails outright, so this one is loud.
• license-files = ["LICENSE"] — hatchling shipped LICENSE in the wheel on its own; uv_build does not. Apache-2.0 requires redistributing the licence with the work, so without this line the wheel would quietly stop carrying it. I only caught this by diffing the two wheels file by file.

Verified on the produced artifacts

• uvx twine check passes on both distributions.
• The wheel still ships clever_cloud/py.typed, and now dist-info/licenses/LICENSE again.
• The 236 tests pass against the built wheel installed in an isolated environment (uv run --isolated --no-project --with dist/*.whl), not just against the source tree.
• Wheel contents are otherwise identical to hatchling's, and the METADATA differences are ordering only — same dependencies, same requires-python, same URLs and keywords.

Two behaviours worth knowing

• uv_build rewrites pyproject.toml inside the sdist as normalised TOML, dropping every comment, and keeps the original as pyproject.toml.orig. So the sdist carries two copies of the file. No effect on installation, but it is surprising the first time.
• Metadata-Version is 2.4 rather than hatchling's 2.5. PyPI accepts both.

Timing

I would not rebuild the v0.2.0 artifacts with this. The tag and the GitHub release already carry hatchling-built distributions that have been checked, and re-tagging a published tag is worse than a one-version backend inconsistency. Publish 0.2.0 as it stands; this takes effect from the next version.

Conflict

Touches the same pyproject.toml block as #5, which adds CHANGELOG.md to the sdist. Resolution is trivial — the [tool.uv.build-backend] block here replaces the [tool.hatch.build.targets.*] blocks entirely, and source-include already lists CHANGELOG.md. Merge #5 first and I will rebase, or merge this one first and #5 drops that hunk.