Bump version: 4.4.0 → 4.5.0

[vhmartinezm]

Release bump for 4.5.0 — rules list --sort active-first and --exclude-favorites.

The SDK floor polyswarm_api>=4.5.0 is already pinned in pyproject.toml. polyswarm-api Release 4.5.0 must be on PyPI before the develop → master release merge, or an install from the index cannot satisfy that floor.

Merge this before the release PR, otherwise that PR promotes 4.4.0 a second time.

[claude]

Review — mechanics clean, release contents under-described

The bump itself is by the book: all three version sites move together ([project] version, [tool.bumpversion] current_version, src/polyswarm/__init__.py), base is develop, and the diff is the exact shape of the previous bump PR (#268). The SDK floor is already polyswarm_api>=4.5.0 from #270, so nothing else is due here — per specs/05-sdk-contract.md §Version pin, "To merge here: the SDK's develop must declare at least the floor. Nothing about PyPI applies yet"; the PyPI precondition you note is PR #271's gate, not this one.

1. The release is described as only the rules list flags, but it also ships PR #267

This PR's body/commit message and PR #271's body both describe 4.5.0 as rules list --sort active-first and --exclude-favorites. Release 4.4.0 merged to master on 2026-09-08; PR #267 (feat(text): render matched strings on hunt results) merged to develop on 2026-09-10 and appears in PR #271's commit list. So 4.5.0 also ships the matched-strings rendering.

That is a behaviour change to unchanged invocations: formatters/text.py:295,328 now appends _matched_strings(...) to every historical/live hunt result, so text output for hunt-result commands gains a Matched Strings: block (and, for [], a standalone none -- the rule matched without byte evidence line; None alone stays silent) — new lines a caller parsing text output sees without changing their command line.

specs/05-sdk-contract.md is explicit that this has to be called out at exactly this cutoff:

Behaviour changes to existing invocations are called out at the same cutoff. This repo has no CHANGELOG, so a change that alters what an unchanged command line does … is visible to users only if the develop → master PR says so. List them there … A note that lives only in a spec is not a release note.

PR #271 already does this well for the rules list dedupe; the fix is to add the matched-strings block to its Behaviour change section (and, since this PR's description enumerates the release contents, here too). The minor bump is already appropriate.

Nothing else actionable — gitflow, version sites and the pin are all consistent with the documented conventions.