Packaging: ship the skill catalog as package data in the pipefy wheel #699

Problem

No published artifact contains the skills:

• The SDK wheel packages only src/pipefy_sdk, with no include or force-include (packages/sdk/pyproject.toml). The mcp and cli wheels do the same.
• The GitHub Release attaches only dist/*.whl (.github/workflows/release.yml).
• Skills reach users only through skills.sh (it reads the repo directly), the Cursor plugin manifest, or git clone.

A Python consumer therefore cannot pin a skill version. It also cannot guarantee that the skills it loads name methods that exist in the pipefy version it installed.

Proposal

• Ship the skill catalog as package data in the pipefy (SDK) wheel, flattened to <skill-name>/SKILL.md plus any references/ files. Many agent frameworks load skills in this one-level layout.
• Add a small accessor, for example pipefy_sdk.skills.directory() -> pathlib.Path, so consumers do not hard-code the location inside the package.
• Honor the surfaces field from the frontmatter issue in this milestone. Either ship only skills that apply to the SDK, or ship all of them and let the consumer filter.

With this change, the skills and the tool names that they cite always come from the same release.

Packaging detail

skills/ is at the repo root, outside the SDK package root (packages/sdk, packages = ["src/pipefy_sdk"]). A plain packages entry cannot reach it. The build needs a hatch force-include that maps ../../skills into pipefy_sdk/skills, or a build step that copies the files in.

release.yml builds --wheel --sdist. The sdist must carry the files too, or an install from the sdist has no skills. PyPI gets only the wheels today, but a local sdist build is still a supported path. A test should assert that the built wheel contains pipefy_sdk/skills/<name>/SKILL.md for every skill that applies to the SDK.

Non-breaking

This change only adds files to the wheel. The repo layout that skills.sh and the Cursor plugin read stays the same.