Add JFrog publish workflow for pyiceberg

[robreeves]

Rationale for this change

Publish the pyiceberg package to the same JFrog Artifactory PyPI repository (openhouse-pypi) used by the OpenHouse data loader.

How it works

1. tag — reads the version from pyproject.toml as the initial version, then auto-increments the patch via git tags on each push to li-0.11 (e.g. v0.11.1, v0.11.2, ...)
2. build — reuses pypi-build-artifacts.yml to build sdist and multi-platform wheels (Linux, Linux ARM, Windows, macOS Intel, macOS ARM) across Python 3.10–3.13 via cibuildwheel. Each wheel is validated by running pytest tests/avro/test_decoder.py.
3. publish — downloads all build artifacts and publishes to JFrog using pypa/gh-action-pypi-publish. Jobs are sequenced via needs: so publish waits for all matrix builds to complete.

This does not publish to PyPI or TestPyPI. The existing upstream workflows (nightly-pypi-build.yml, python-release.yml) are gated by github.repository == 'apache/iceberg-python' and will not run in this fork.

Requires JFROG_USERNAME and JFROG_PYPI_API_TOKEN secrets to be configured in this repo.

Are these changes tested?

Will be validated on the first push to li-0.11 after secrets are configured.

Are there any user-facing changes?

No.

[Copilot]

Pull request overview

Adds a GitHub Actions workflow to automatically tag, build, and publish pyiceberg artifacts to the LinkedIn JFrog Artifactory PyPI repo (openhouse-pypi) on pushes to the li-0.11 branch.

Changes:

• Introduces a tag job that derives the initial version from pyproject.toml, bumps the patch version, and pushes a git tag.
• Reuses the existing pypi-build-artifacts.yml reusable workflow to build sdist and multi-platform wheels for the computed version.
• Publishes the built artifacts to JFrog Artifactory using pypa/gh-action-pypi-publish.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The workflow performs a mutating operation (creating/pushing git tags) on every push to li-0.11, but there is no concurrency configured. If multiple pushes happen close together, concurrent runs can race and either fail to push the tag or publish artifacts for a different tag than expected. Consider adding a workflow-level concurrency group keyed by github.ref (and queue runs rather than cancel) to ensure tag/build/publish execute serially for the branch.

Suggested change

	concurrency:
	group: jfrog-publish-${{ github.ref }}
	cancel-in-progress: false

[Copilot]

permissions: contents: write is set at the workflow level, so all jobs (including build/publish) receive write access to the repo contents. To follow least-privilege, consider setting workflow-level permissions to contents: read (or omit), and grant contents: write only on the tag job (where pushing tags is needed).

Suggested change

	contents: write
	jobs:
	tag:
	contents: read
	jobs:
	tag:
	permissions:
	contents: write