release: 0.30.0

[Faisal-Fayaz]

Publishing 0.30.0

Four security fixes have been sitting on main unpublished, because release.yml triggers on paths: [src/sk/__init__.py] and no bump ever happened. PyPI users were still on 0.29.0-era handling:

71881e7	~/.sidekick is now 0700 dirs / 0600 files
bc5ce0f	API keys masked as **** rather than first3…last4
ff5b5e9	the egress allowlist is enforced on every redirect hop
8200f58	PreToolUse hooks fail closed; silent writes are reported

The one that matters

ff5b5e9. Allowlist a host you trust, let it 302 anywhere, and the agent fetched the target and returned the content to the model:

allowlist : ('ok.example',)   evil.test NOT allowed
HOPS      : ['https://ok.example/start', 'https://evil.test/payload']
OUTPUT    : 'SECRET PAYLOAD FROM EVIL'

That is precisely the threat #328 exists to stop — an attacker choosing a destination, not the user choosing their own provider — and docs/egress.md already claimed both checks ran on every hop.

One test change, and why it's a correction rather than a loosening

test_aur_pkgver_tracks_the_source replaces a strict-equality assertion. Strict equality was wrong, not merely inconvenient: the pinned sdist must exist on PyPI, and a release bump necessarily lands before AUR is repinned — so it would fail every release PR for a lag that is correct at that moment.

The rule is now one-sided and bounded:

• pkgver may not point ahead of the source (that sdist doesn't exist → cannot build)
• pkgver may not lag by more than one minor

Both directions are tested, so it still catches the three-release drift (0.26.0 vs 0.29.0) that this test was written for.

Verification before publishing

ROADMAP.md records the release and Next points at 0.31.0, per CONTRIBUTING.md. The release workflow's own Verify release sequence step will run at publish time — that's where the tag-sequence guard lives, since CI checks out at fetch-depth 1 and skips it.

1389 passed, ruff clean, coverage 79.89%.