4.5.0

• polyswarm rules list gains --sort active-first: rulesets whose live hunt is running list first, newest first within each block. Default output is unchanged.
• Behaviour change to rules list regardless of the flag: the walk now emits each ruleset at most once per run, keyed on id. rules list pages through every result and exposes no limit, so it is the consumer that has to absorb a mutable order.
• Two costs of that, documented in --help and in the command docstring. The surviving copy is the stale one — first-wins is the only option for a streaming printer, and that copy carries the values from before the transition, so the deduplicated row prints the Live Hunt Id of a hunt that has already stopped. And a ruleset whose hunt starts mid-walk moves above the cursor and never reaches the client at all; a re-run lists it.
• The active-first order ranks on the stored hunt link, which is wider than the rendered Live Hunt Id: a ruleset whose hunt was stopped without clearing the link ranks in the leading block while rendering an empty Live Hunt Id. Read the field, not the position.
• rules list gains --exclude-favorites, the inverse of --favorites-only; the server refuses the two together. For a caller that renders the favorites as their own list and would otherwise see a page repeat a row or come back short.
• Hunt results render matched strings — the yara strings behind a hit — and say when the server's byte budget withheld some of them, instead of silently dropping the count.
• SDK floor raised to polyswarm_api>=4.5.0, the release that adds ruleset_list(sort=).