feat: prepare duckflow for PyPI submission

[Copilot]

Summary

Prepares the duckflow package for submission to PyPI.

Note: The GitHub issue and devel branch were created as part of this work. The devel branch was created locally from main; all changes were committed there and pushed through the agent's working branch per the agent environment constraints.

Changes

pyproject.toml

• Updated license to use a SPDX string ("AGPL-3.0-or-later") — the modern format that avoids setuptools deprecation warnings and aligns with PEP 639
• Removed the now-redundant License :: classifier (setuptools ≥ 77 auto-generates it from the SPDX expression)
• Added keywords for PyPI discoverability
• Added [project.urls] — Homepage, Source, Bug Tracker, Changelog
• Added classifiers: Operating System :: OS Independent, Python :: 3.13, Topic :: Software Development :: Documentation, Topic :: Software Development :: Libraries :: Python Modules, Typing :: Typed
• Added build>=1.0 and twine>=5.0 to the [dev] extras so maintainers can build and verify locally

CHANGELOG.md (new)

• Initial changelog following Keep a Changelog format with a v0.1.0 entry

.github/workflows/publish.yml (new)

• Publishes to PyPI automatically when a GitHub Release is published
• Uses Trusted Publisher (OIDC) — no API token needed
• Build job (contents: read) builds and twine checks the distribution, then uploads as a workflow artifact
• Publish job (id-token: write) downloads the artifact and publishes via pypa/gh-action-pypi-publish

README.md

• Added PyPI version, Python versions, and License badges
• Added pip install duckflow as the primary install path (with dev editable install as secondary)

Verification

• python -m build — clean build, no warnings
• twine check dist/* — PASSED for both wheel and sdist
• pytest — all 8 existing tests pass

Next steps before publishing

1. Register a Trusted Publisher on PyPI for the Warnes-Innovations/duckflow repository targeting the publish.yml workflow and the pypi environment
2. Create a pypi environment in GitHub repository Settings → Environments
3. Tag a release (git tag v0.1.0 && git push origin v0.1.0) and publish it on GitHub to trigger the workflow

[Copilot]

Pull request overview

Prepares the duckflow package and repository metadata for an initial PyPI release, including packaging metadata updates, release notes, and an automated publish workflow.

Changes:

• Update pyproject.toml project metadata (license format, keywords, classifiers, URLs) and expand dev extras for release tooling.
• Add an initial CHANGELOG.md following Keep a Changelog format.
• Add a GitHub Actions workflow to build and publish distributions to PyPI on GitHub Release publish, plus README install/badges updates.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
README.md	Adds PyPI-facing badges and a primary pip install duckflow install path.
pyproject.toml	Updates packaging metadata for PyPI readiness and adds build/publish tooling to dev extras.
CHANGELOG.md	Introduces a v0.1.0 changelog entry and standard compare/release links.
.github/workflows/publish.yml	Adds CI workflow to build, check, and publish to PyPI via Trusted Publishing (OIDC).

---

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

[Copilot]

The workflow sets explicit permissions for the build job but only grants contents: read. actions/upload-artifact typically requires actions: write on the job’s GITHUB_TOKEN; without it, the artifact upload can fail with permission errors. Add actions: write (or remove the restrictive permissions block if repo defaults are acceptable).

Suggested change

	contents: read
	contents: read
	actions: write

[Copilot]

The publish job sets permissions to only id-token: write, which can leave the job without the actions: read permission needed for actions/download-artifact to fetch artifacts from the build job. Consider adding actions: read (and any other required scopes) alongside id-token: write.

[Copilot]

license was changed to an SPDX expression string and the license classifier was removed, but [build-system].requires still allows setuptools>=69. Your PR description notes behavior for setuptools>=77; if older setuptools versions are used, metadata generation may differ or fail. Either raise the minimum setuptools version in [build-system].requires to match the metadata expectations, or keep the older license/classifier format for broader compatibility.