Fix packaging metadata and repository URLs

[glopesdev]

Four of the five published distributions carry no license, no long description, no classifiers and no links. Verified against built wheels rather than config: harp reports License-Expression, a bundled LICENSE, twelve classifiers, five Project-URL entries and a long description, while harp-protocol, harp-device, harp-serial and harp-data report a summary and nothing else. So the page for the package a user installs to get the protocol layer would be blank, with no license and no route back to the repository.

All four now declare authors, license, license-files, readme, the same twelve classifiers as the umbrella, and the same five URLs. harp-protocol already had authors and license, so it gained only what was missing.

Why the license text is duplicated per package

PEP 639 is explicit that license-files patterns are relative to the directory holding pyproject.toml and that "Parent directory indicators (..) MUST NOT be used". So no compliant backend can declare a shared license from outside the package directory. Setuptools makes this worse than a plain error: license-files = ["../../../LICENSE"] builds successfully and emits License-Expression, while silently shipping no file and no License-File entry, which is how a wheel ends up claiming MIT and carrying no license text. A package-local copy produces both.

This is also what comparable projects do: opentelemetry-python, which publishes dozens of distributions from one repository, keeps a LICENSE beside every pyproject.toml.

URLs after the rename

The repository is now harp-tech/python, so every URL follows. Three of the twelve edits were not metadata: the root README logo was pinned to a raw.githubusercontent.com URL, which is the one form that does not follow a rename, and four API links in the same README pointed at the old documentation path. mkdocs.yml gains site_url, which was unset, so the published location is declared in one place.

Attaching the READMEs is also what made their relative sibling links load-bearing, since a relative link resolves nowhere on a project page. They are now absolute, which incidentally takes mkdocs build --strict from six unrecognized relative links to zero.

Deliberately unchanged

Inter-package dependencies stay unpinned for now. Only release candidates have been tagged so far, and pip excludes pre-releases unless the specifier names one, so a >=0.5 floor would refuse 0.5.0rc2, while an exact pin cannot be expressed in static metadata against a version derived from the tag.

Sibling links point at tree/main rather than at commit permalinks or at the documentation site. A permalink fails in the worse direction, staying valid while showing an old tree, and the documentation site does not exist until the first non-prerelease deploy. This will happen soon, but would be good to decide first what our approach for per-version docs will be, so I deferred it.