Release v3.3.1 · renatobo/eventon-apify

New Features

The REST readiness ratchet now pins each handler to its own capability toggle. It already proved that every registered endpoint refuses to run with the API master switch off and with EventON absent, but both of those pass for any handler that calls an assert at all. A handler passing the wrong capability name, or the no-capability eventon_apify_assert_api_is_ready(), would have kept responding while its switch read off in Settings. The test now maps each route and method to its capability, checks that map against both the capability definitions and the registered endpoint list so a new route cannot skip it, and turns exactly one capability off per endpoint.
Corrected the return annotation on eventon_apify_get_events_database_response(), which returns a WP_Error for a rejected status filter rather than only an array. No behavior change: the caller passes the result to rest_ensure_response(), which hands a WP_Error straight back to the client, so a bad status filter has always produced its documented 400.

No endpoint, payload, option, or capability behavior changes in this release. It adds test coverage and corrects an inaccurate docblock.
Only the refusal direction of the capability gate is asserted. The mirror case, that a handler runs when its own capability is the only one enabled, cannot be covered by the unit harness: past the assert the handlers reach rest_ensure_response() and other core functions the hand-written stubs do not implement. Every case in that file works by short-circuiting before that point.