Pull request 47: the project moves from pip to uv

This pull request makes uv the only Python toolchain for the MikroTik MCP server. pip and setuptools are gone, the build backend is hatchling, and a committed lock file pins every dependency with hashes. CI, the release pipeline, the Docker image and local development all install from that same frozen lock.

The author measured creating a fresh environment and installing everything. With pip it took about thirteen seconds. With uv it takes under one, roughly sixteen times faster. The bigger win is reproducibility. pip had no lock file, so two installs could resolve different versions. Now every flow installs the same hash-verified set.

CI gets a gate that fails any pull request whose pyproject changed without a matching lock file. A second job builds the wheel and checks both documented install paths, uvx and pip with python -m mcp_mikrotik, and confirms that Python below 3.10 is refused. The release build is gated on a current lock, and the MCP publisher is pinned and checksum verified.

The first reviewer asked for strong test results, because swapping the toolchain is a core change. The author compared the published version, a local uv build and the Docker image on a real RouterOS 7.22 router. More than 45 read-only tool calls gave identical output. After the final rebase, the unit tests pass on three Python versions from the frozen lock, and the Docker image is about 150 megabytes against 200 for the published one.

Some limits remain. A plain pip install of the published package still resolves version ranges, so the exact pin guarantee only covers uv flows. The arm64 Docker build was not run, only checked statically. And merging triggers a release, so that release is the first real run of uv build and the pinned publisher. If you maintain releases, watch that run.