Treat 404-with-resources as success in action discovery

[mraible]

The Fusion search_activities API returns a top-level HTTP 404 when a result set includes an action whose backing catalog artifact is missing, even though it still returns every action it could resolve. The unresolvable ids come back separately under body.errors; the usable actions are in body.resources, and meta.pagination.total reflects the full match count.

The FalconPy migration keyed success off the aggregate status_code, so any non-200 discarded the valid resources and returned None (or raised). Because common searches (for example name:'email', which matches many actions) happen to include an orphaned entry, they returned a 404-with-results and looked like transient failures, forcing a fallback to the slow full-catalog scan or hardcoded action ids. The earlier curl-based implementation read resources directly off the body and never gated on an aggregate status, so this is a regression introduced by the SDK migration.

This is confirmed server-side, not a client issue: a raw HTTP request with no SDK in the path returns the same 404-with-results, and the SDK faithfully passes the status through.

Fix

Add _usable_body(resp), which returns the response body whenever it carries resources regardless of the aggregate status, and only treats a non-200 with no resources as a real failure. Route _fql_search, _fetch_page_with_retry, list_actions, and get_action_details through it. Because the API places orphaned entries in errors rather than resources, they are naturally excluded from results, no separate filtering needed.

Testing

Adds a TestUsableBody class covering the 200, partial-404-with-resources, 404-without-resources, 500, and missing-body cases. The full test_action_search.py suite passes (16 tests) and pylint stays at 10.00/10.