Make filtered-notification integration test idempotent (#144)

[milmazz]

Summary

Fixes the second failure in #144 (filtered notifications become requests that can be accepted) and documents why the first one can't be fixed here.

• Accepting a notification request grants the sender a permanent NotificationPermission, so any re-run against a reused database found kadaba's mentions no longer filtered (FilterCondition#override_for_sender?) and timed out waiting for a NotificationRequest.
• Mastodon has no API to revoke the permission directly, but BlockService destroys it (present in both v4.4.8 and v4.6.1), so the test now resets it with a block/unblock pair at the start and in on_exit, making it self-healing on reused databases.

Investigation findings for the rest of #144

• On a truly fresh database the test passes against Mastodon 4.6.1 too — the failure reported in Two integration tests fail against Mastodon 4.6: scheduled-status idempotency (500) and filtered-notification requests #144 was leftover state, not a 4.6 behavior change.
• The remaining failure (second POST /api/v1/statuses with the same Idempotency-Key → 500) is an upstream Mastodon 4.6 regression, still present on main: the with_idempotency refactor in PostStatusService returns the duplicate from the helper's own scope, call continues with @status = nil, and postprocess_status! crashes in ProcessHashtagsService (NoMethodError: undefined method 'account' for nil). Reproducible with plain curl. Nothing in Hunter can fix it; it blocks bumping CI toward 4.6 unless that assertion is version-guarded.

Test plan

• Reproduced the failure on a reused 4.6.1 database (leftover permission), then verified the fixed test passes 3 consecutive runs there
• Fresh 4.4.8 stack (CI-pinned images): full integration suite 29 tests, 0 failures

Refs #144

🤖 Generated with Claude Code