Adopt a proper cross-package dependency strategy for the monorepo (evaluate `uv` workspaces)

[s-heppner]

Currently, the three packages in this monorepo (sdk, compliance_tool, server) each handle their inter-package dependency on basyx-python-sdk differently, and none of them enforce the compatibility the monorepo is supposed to guarantee:

• compliance_tool/pyproject.toml declares a plain version constraint (basyx-python-sdk>=1.0.0). This publishes cleanly to PyPI, but the pin is deliberately loose. For local development it relies on the convention that ./sdk is installed first (so the already-installed sibling satisfies the constraint), and nothing actually ties it to the compatible SDK state.
• server/pyproject.toml does not declare basyx-python-sdk as a dependency at all; its Dockerfiles install it manually (RUN pip install ../../sdk then RUN pip install ..), so the DockerHub publish works but the package itself is not self-describing. Already tracked as Introduce SDK as dependency for server #459.

I've encountered this underlying tension quite often now. The whole point of the monorepo is that the three packages have mutually compatible states, so a local install should use the sibling ./sdk tree, while a published install should pull the compatible version from PyPI. There are two ways to resolve this:

• Stay on setuptools, keep a normal version constraint, and formalize the install-ordering convention (install ./sdk editable first so it satisfies the constraint). This is low-churn and already roughly how things work, but nothing enforces the ordering, and expressing a correct lockstep pin is awkward with setuptools_scm-derived versions.
• Migrate to uv workspaces. [project.dependencies] keeps a normal constraint (basyx-python-sdk), and [tool.uv.sources] with { workspace = true } points at the local sibling for development. That source is dev-only metadata that uv strips from the published wheel, so local resolves to ./sdk and the published artifact carries only the PyPI constraint — the behavior we keep reaching for, enforced by the tool rather than by convention.

We should decide between these and, if we go with uv, migrate the packaging/dependency management for all three packages and their release workflows, settling on the correct lockstep version constraint between them. This would subsume the server-specific fix in #459.