Version-lock PyPI publish to dispatched daemon version

[TeoSlayer]

Why

A web4 (daemon) release reached no downstream channel. PyPI is stuck at 1.10.5 because nobody creates a release in this repo, and the publish workflow had no version input and shipped a binary-less wheel (it ran python -m build directly; the old build-binaries.sh is a dead cd ../../.. leftover from the monorepo era).

What

Rewrites publish.yml so it:

• Adds a version workflow_dispatch input (the canonical trigger — web4's release pipeline dispatches it at the daemon tag, e.g. 1.12.3). Keeps the legacy release: published trigger.
• Pins pyproject.toml version to the dispatched version → the wheel is version-locked to the daemon, not to stale source.
• Bundles the native runtime (pilot-daemon, pilotctl, pilot-gateway, pilot-updater, libpilot.{so,dylib}) under pilotprotocol/bin/, built from source: libpilot (CGO shared lib) from pilot-protocol/libpilot against the same sibling-module checkout set libpilot CI uses; daemon binaries from web4 at the matching tag.
• Builds a Linux (manylinux-repaired) + macOS wheel + sdist, twine checks, and skips if the version already exists on PyPI (idempotent).

Requires existing secret PYPI_API_TOKEN (present).

Part of the release fan-out (web4 + sdk-node + this).

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[TeoSlayer]

Verified end-to-end: dispatched this branch with version=1.12.3 and published pilotprotocol 1.12.3 to PyPI (now latest): manylinux + macOS platform wheels (native binaries bundled) plus sdist.

Root cause of the prior PyPI failure uncovered + fixed here: twine rejected the dist with InvalidDistribution: malformed field 'license-file' (modern setuptools emits Metadata-Version 2.4; the runner's system twine was too old). The publish job now uses actions/setup-python + twine>=6.1.