docs(cli): install pipefy-cli from PyPI instead of git+subdirectory

[gbrlcustodio]

What

Addresses the reframed goal of #234: move the CLI install path off git+…#subdirectory=packages/cli references (with --with sibling pins) onto plain PyPI installs, mirroring what #368 did for the MCP server.

All four packages now publish to PyPI on every tag (#365), so pipefy-cli resolves pipefy and pipefy-auth transitively. Installs no longer pay a git clone plus build, and the manual --with chains are gone.

The .mcp.json / MCP-server half already landed in #368; this closes out the remaining CLI half.

Changes

• commands/install.md (/pipefy:install): uv tool install --force pipefy-cli.
• README.md, packages/cli/README.md, docs/MIGRATION.md: install snippets use uvx --from pipefy-cli pipefy … / uv tool install pipefy-cli, with the PyPI-resolution note (no --prerelease allow).
• RELEASE.md: verification snippets move to PyPI (PEP 440 pins); removed the now-vestigial latest moving-tag step (nothing consumes @latest after the switch) and the non-installable repo-root git examples.
• CHANGELOG.md: [Unreleased] entry for the cutover.

Two latent bugs fixed along the way: the console script is pipefy (not pipefy-cli), and dropping the global --prerelease allow per #368's 6debb7f8 (it lets transitive deps pull their own broken pre-releases).

Verification

• uvx --from pipefy-cli pipefy --version, uv tool install pipefy-cli, and the pinned-prerelease forms all resolve from PyPI (0.3.0a1) with no git clone.
• No git+…/ai-toolkit install refs or @latest moving-tag references remain outside CHANGELOG.md.

Closes #234.

[adriannoes]

Solid docs-only follow-up that completes the CLI install cutover #368 left open. All six touched files consistently move from git+…#subdirectory + --with chains to plain PyPI installs, fix the pipefy console-script name in uvx examples, and drop the obsolete latest moving-tag release step. I spot-checked PyPI installs locally (uvx --from pipefy-cli pipefy --version and uvx pipefy-mcp-server --help) — both resolve 0.3.0-alpha.1 without --prerelease allow, matching the documented behavior. CI lint + test are green.

What worked well

• Mirrors the merged MCP PyPI pattern from #368 with the same --prerelease allow rationale.
• Corrects the pipefy vs pipefy-cli entrypoint in documented uvx invocations.
• Removes vestigial @latest / moving-tag release mechanics from RELEASE.md.
• Thorough CHANGELOG entry ties the cutover to #234 and #368.

Also noted (non-blocking)

• README.md still labels v0.2.0-beta.* as the "current beta line" in the install callout while the pin example uses 0.3.0a1; consider aligning that sentence when convenient.

[gbrlcustodio]

Fixed in bdb6537: the callout was doubly stale, so I updated it to the current pre-release line v0.3.0-alpha.* (first tag v0.3.0-alpha.1), which now matches the 0.3.0a1 pin example. Reflects the move from the beta to the alpha line too.

[adriannoes]

Re-reviewed after the follow-up commits. The README pre-release callout now correctly points at the v0.3.0-alpha.* line (addressing the earlier wording note), and the dev merge resolved CHANGELOG.md cleanly — Added entries from dev sit above the PyPI install Changed entry with no duplication. The net diff vs dev is still the same six doc files; CI (lint, test, skills-lint) is green, and uvx --from pipefy-cli pipefy --version still resolves 0.3.0-alpha.1 from PyPI without --prerelease allow.

What worked well

• Responsive fix for the version narrative in the install callout.
• Clean CHANGELOG conflict resolution after merging dev.
• Consistent PyPI install story across README, CLI README, MIGRATION, commands/install.md, and RELEASE.md.
• Thorough CHANGELOG entry tying the cutover to #234 and #368.

Verification

uvx --from pipefy-cli pipefy --version
uv tool install pipefy-cli