fix: backport manylinux_2_28 wheel build to v0.1.4 (post1 release)

[kiran-thumma]

Summary

Backport PR #386 ("support glibc 2.28") onto v0.1.4 to produce flydsl==0.1.4.post1 wheels with manylinux_2_27/manylinux_2_28 platform tags.

Problem

flydsl==0.1.4 wheels on PyPI and AMD mirrors are only available as manylinux_2_35 (requires glibc 2.35+). This makes them uninstallable on:

• AITER's manylinux_2_28 build container (glibc 2.28)
• RHEL 8 / CentOS Stream 8 (glibc 2.28)
• Ubuntu 20.04 (glibc 2.31)

Since amd-aiter v0.1.13 pins Requires-Dist: flydsl==0.1.4, any downstream install of aiter fails on these platforms.

$ pip install flydsl==0.1.4
ERROR: No matching distribution found for flydsl==0.1.4

Tracking issue: #527
Related issue: #396 (centos install failed — still open, same root cause)

What this PR does

1. Cherry-picks PR support glibc2.28 #386 onto the v0.1.4 tag — adds Dockerfile.manylinux_2_28 and updates build-whl.yaml to build against glibc 2.28
2. Bumps version to 0.1.4.post1 — PyPI doesn't allow re-uploading the same version

Expected output

Version	Platform tags	glibc 2.28 install
flydsl-0.1.4 (existing)	manylinux_2_35	No
flydsl-0.1.4.post1 (this PR)	manylinux_2_27 / manylinux_2_28	Yes

Since pip install flydsl==0.1.4 auto-resolves to 0.1.4.post1 (PEP 440), no downstream pin changes needed.

Test plan

• Trigger CI with skip_promote=true to build wheels to staging
• Verify wheel platform tags are manylinux_2_27_x86_64 or manylinux_2_28_x86_64
• Test install in manylinux_2_28 container:

  pip install --extra-index-url https://rocm.frameworks-devreleases.amd.com/whl-staging/gfx942-gfx950/ flydsl==0.1.4.post1

• Verify amd-aiter v0.1.13 installs cleanly with the new wheel
• After validation, promote to PyPI

After merge

• Publish 0.1.4.post1 wheels to PyPI
• Revert AITER's workaround pin from flydsl==0.1.6 back to flydsl==0.1.4
• Close [request] Backport manylinux_2_27/2_28 wheels for v0.1.4 (post1 release) #527 and [Issue]: centos install failed #396