fix(deps): allow uipath-runtime 0.13.x on the 0.0.84 line

[radu-mocanu]

Releases uipath-dev 0.0.84.post1 with a single dependency-requirement change.

-version = "0.0.84"
+version = "0.0.84.post1"
-  "uipath-runtime>=0.12.1, <0.13.0",
+  "uipath-runtime>=0.12.1, <0.14.0",

Why

0.0.84 caps uipath-runtime below 0.13.0, and 0.0.85 requires uipath>=2.14.1. A consumer that stays on the uipath 2.13 line therefore has no published uipath-dev that admits uipath-runtime 0.13.x: 0.0.84 excludes the runtime, 0.0.85 excludes the SDK. Since uipath-dev sits in consumers' dev groups, that blocks uv lock even though the tool never ships in their wheel.

uipath>=2.13.0, <2.14.0 is left alone, so this release stays on the 2.13 SDK line.

Versioning

0.0.85 already exists, so per the open-source hotfix procedure this is a post-release of the version being fixed rather than a patch increment. PEP 440 orders it 0.0.84 < 0.0.84.post1 < 0.0.85, so it does not supersede 0.0.85 for anyone already on it.

Branch

Cut from 93fe8f5, the commit that built 0.0.84. Base branch base/uipath-dev-0.0.84.x is that same commit. Not for main, which is already past 0.0.85.

Verification

• uv lock regenerated, uv sync --locked --all-extras clean
• test suite green, 21 passed

Publishing

CD is workflow_dispatch. Dispatch against the hotfix branch after merge, and note it must land after uipath 2.13.23 is on PyPI, since locking this line at uipath-runtime 0.13.x needs an SDK on the 2.13 line that permits it.

[radu-mocanu]

Closing: not needed, same reason as UiPath/uipath-python#1876.

Making the 0.0.84 line accept uipath-runtime 0.13.x requires >=0.13.0, <0.14.0, not the two-minor widening proposed here, and 0.0.85 already ships exactly that. The consumer moves its dev group to 0.0.85 instead, alongside uipath 2.14.1 which 0.0.85 requires. No release is needed on the 0.0.84 line.