fix(cli): only claim uipath new scaffolds for langchain agents

[vldcmp-uipath]

Important

Draft until UiPath/uipath-python#1886 is approved and uipath 2.14.15 is published. The middleware imports uipath._cli.models.project_types / uipath._cli.models.agent_frameworks, which only exist from 2.14.15. For dev-build validation and TestPyPI publishing, this PR temporarily pins uipath==2.14.15.dev1018867615 (the dev build of #1886) sourced from the testpypi index, with uv.lock resolved against it. Before marking ready for review: restore "uipath>=2.14.15, <2.15.0", drop the [tool.uv.sources] testpypi entry for uipath, and run uv lock.

Problem

langgraph_new_middleware returns should_continue=False unconditionally, so installing uipath-langchain hijacks uipath new process-wide and the base function scaffold becomes unreachable (UiPath/uipath-python#1543). This also breaks the uip function new -l py path, which delegates to uipath new and expects a function project.

Changes

• The middleware now takes project_type / agent_framework (forwarded by uipath new since 2.14.15) and claims the command for --type auto (the default: an installed framework wins, preserving today's behaviour) and for --type agent with the langchain framework; everything else passes through to the base scaffold or another framework's integration.
• Defaults (ProjectType.AGENT / AgentFramework.LANGCHAIN) preserve current behaviour when an older uipath CLI calls with just the project name.
• Comparisons use != rather than identity so callers passing plain strings gate correctly (the enums subclass str).
• Version bumped to 0.17.9; uipath floor raised to 2.14.15.

Behaviour with uipath >= 2.14.15

Command	Result
uipath new my-fn (or --type auto)	LangGraph agent project (auto default: installed framework claims it)
uipath new my-fn --type function	function project (guaranteed — previously unreachable)
uipath new my-agent --type agent	LangGraph agent project (unchanged)
uipath new x --type agent --agent-framework pydantic-ai	passes through to that framework's integration

Testing

• 9/9 in tests/cli/test_new.py (7 new cases incl. plain-string gating and old-CLI default), mypy and ruff clean, run against the TestPyPI dev build uipath==2.14.15.dev1018867615.
• Verified end-to-end in a venv with both packages installed editable.

🤖 Generated with Claude Code

Development Package

• Use uipath pack --nolock to get the latest dev build from this PR (requires version range).
• Add this package as a dependency in your pyproject.toml:

[project]
dependencies = [
  # Exact version:
  "uipath-langchain==0.17.9.dev1010695775",

  # Any version from PR
  "uipath-langchain>=0.17.9.dev1010690000,<0.17.9.dev1010700000"
]

[[tool.uv.index]]
name = "testpypi"
url = "https://test.pypi.org/simple/"
publish-url = "https://test.pypi.org/legacy/"
explicit = true

[tool.uv.sources]
uipath-langchain = { index = "testpypi" }

[tool.uv]
override-dependencies = [
    "uipath-langchain>=0.17.9.dev1010690000,<0.17.9.dev1010700000",
]

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[vldcmp-uipath]

Superseded by UiPath/uipath-python#1886, which fixes #1543 entirely in the base CLI.

uipath new is the only caller of the new middleware chain, so it can simply not consult the chain when --type function is requested. That makes the gate this PR added unnecessary: an installed uipath-langchain can no longer intercept a function scaffold, whatever version it is.

So this integration needs no changes at all — Middlewares.next("new", name) is unchanged, which also means no uipath floor bump, no TestPyPI pin and no release ordering between the two repos. Verified end-to-end against the current main build of this package: uipath new x still scaffolds the LangGraph agent, --type function now reaches the base function scaffold, and --type agent scaffolds the agent.