Python wheel platform tagging is a no-op: four platforms share one py3-none-any filename

[bahdotsh]

Split out of #314, which deliberately excludes the Python wheels from the release assets for this reason.

The bug

python-package in .github/workflows/release.yml builds a wheel per platform across a four-entry matrix, but the platform tag never reaches the wheel:

• matrix.plat_name (macosx_14_0_arm64, manylinux_2_17_x86_64, manylinux_2_17_aarch64, win_amd64) is referenced nowhere in the job body.
• The step captioned "Re-tag the wheel with the correct platform" only iterates glob.glob('dist/*.whl') and prints the filenames. It re-tags nothing.

The package has no ext modules, so setuptools emits offline_protocol_sdk-<version>-py3-none-any.whl for all four. One filename, four different native libraries.

Consequences:

1. The four python-wheel-* artifacts each contain an identically-named wheel. Attaching them to a release would collide on upload.
2. Any one of them that landed would be a wheel pip installs happily on the wrong platform, producing a load failure at import rather than a resolver error at install.

manylinux_2_17_* is also inaccurate independent of the tagging: the Linux libraries are built on ubuntu-latest, so they carry that image's glibc floor, not 2.17.

Fix sketch

Set the tag at build time rather than after the fact — either python -m build --wheel -C--build-option=--plat-name=${{ matrix.plat_name }}, or wheel tags --platform-tag on the built artifact, or a bdist_wheel subclass with root_is_pure = False. Whichever route, the job needs an assertion that the emitted filename actually carries the tag, since the current failure mode is a silently-wrong wheel.

For the glibc claim: either build in a manylinux container so manylinux_2_17 is true, or tag with the floor the ubuntu-latest build actually produces.

Blocks

Attaching Python wheels to the GitHub release. Everything else shipped in #314.