release: bump version to 4.3.0, floor the SDK at 4.3.0

[sbneto]

TL;DR

• Floors the polyswarm_api dependency at >=4.3.0,<5.0.0 — the release that ships the typed known-good refusal and probe fixes this CLI renders.
• bump-my-version bump minor: 4.2.1 → 4.3.0.

Requires

• polyswarm-api release-4.3.0 → develop (same branch name, so CI here already tests against that SDK branch archive).

[claude]

Review — release: bump to 4.3.0, floor SDK at 4.3.0

Base is develop ✅. Two blockers, both on the floor bump.

1. The >=4.3.0 floor fails both preconditions specs/05-sdk-contract.md sets (blocker — merge ordering)

The floor must be satisfied by the SDK archive CI installs, and by PyPI. […] a floor bump has two preconditions: the version is on PyPI, and the SDK’s develop declares at least that version.

Neither holds right now:

• polyswarm-api 318 (release-4.3.0 → develop) is still OPEN → the SDK’s develop still declares version = "4.2.0".
• polyswarm-api 319 (develop → master, "Release 4.3.0") is still OPEN → 4.3.0 is not published, since the SDK publishes off a master version change.

Consequences, in the exact shape the spec warns about:

• After merge into develop, CI on CLI develop runs pip install $POLYSWARM_API_ARCHIVE/develop.zip (declares 4.2.0), then pip install .[tests] with a >=4.3.0 floor. The archive build no longer satisfies the floor, so pip goes to PyPI — either silently replacing the archive build (spec: "CI stops testing the SDK branch at all — the mechanism §Coordinated changes rests on, defeated with no error") or, since 4.3.0 is not on PyPI, failing resolution outright. This PR’s own CI is green only because CLI branch release-4.3.0 matches an SDK branch of the same name, so $CI_COMMIT_BRANCH.zip hits; that stops being true the moment it lands.
• On reaching master, a floor above the newest published SDK "breaks pip install polyswarm-cli for every consumer" — and this PR is the release bump, so that is one merge away.

Required order: SDK 318 → SDK 319 → SDK 4.3.0 live on PyPI → then this. Worth stating explicitly under the Requires section, which currently links only the branch and cites the same-branch-name CI coverage as reassurance — precisely the coincidence that disappears post-merge.

2. Spec drift — specs/05-sdk-contract.md §"Current floor" not updated (AGENTS.md violation)

That spec carries a dedicated Current floor — polyswarm_api>=4.2.0 section justifying the floor behaviour-by-behaviour, plus the PyPI/develop preconditions. This PR moves the floor and leaves it saying 4.2.0. AGENTS.md: "Update the spec in the same PR as the code change." Add a Current floor — polyswarm_api>=4.3.0 section with the actual justification and the verified version strings (as the 4.2.0 section did), and mind the dev-suffix check the spec calls out.

3. The stated justification is not backed by CLI code

the release that ships the typed known-good refusal and probe fixes this CLI renders

The CLI consumes none of that surface:

• KnownGoodWithheldException appears nowhere in src/ (nor any withheld/refusal handling). It subclasses NotFoundException (SDK 316), which ExceptionHandlingGroup (src/polyswarm/client/polyswarm.py:139) already catches by ancestry → exit 1 on 4.2.0 and 4.3.0 alike.
• The exists() probe fix: the CLI never calls exists() — the only exists hits in src/ are click.Path(exists=True).
• The dict/string error-payload rendering is internal to the SDK’s message construction; the CLI just logger.error(e)s it. A nicer message, not a behaviour the CLI relies on.

specs/05 says: "Floor it at the lowest SDK version that exposes every method/behaviour the CLI relies on." By that test the floor is still 4.2.0 — the same conclusion 262 recorded ("none of the SDK’s new surface (KnownGoodWithheldException) is used by the CLI"). Unlike the 4.2.0 bump, nothing here fails silently on the lower version. Either drop the floor bump (keeps this release installable regardless of SDK release timing, and dissolves item 1) or keep it and record the real reason in specs/05 — a deliberate "CLI 4.3.0 ships against SDK 4.3.0" release pairing is a legitimate justification, it just is not the one in the description.

Minor

• release: is not in AGENTS.md’s conventional-commit prefix list (feat: fix: refactor: chore: docs: test:), and AGENTS.md says "version bumps belong to the develop → master step" — which does not describe this two-step release-branch pattern (mirroring SDK 318/319). If that is the intended flow, AGENTS.md §Gitflow should say so ("Update it when major workflow decisions land").