Decide a consistent convention for graceful degradation when Redis is unavailable

Proposed Changes

NetBox has no consistent convention for how code should behave when Redis is unavailable. Redis-touching paths currently take one of two stances, and there is no shared guidance on which to use when:

• Refuse up front. The any_workers_for_queue() callers gate work and surface an error if no worker is available: script run views (netbox/extras/views.py, netbox/extras/api/views.py) and the bulk async API (netbox/api/viewsets/mixins.py).
• Let the error propagate. Webhook enqueue (netbox/extras/events.py, where rq_queue.enqueue(...) is unguarded), the dashboard/status worker count (get_all_workers() in netbox/core/views.py and netbox/api/views.py), and the config-revision cache (netbox/config/__init__.py, which guards DatabaseError but not a Redis failure on cache.get).

No production (non-test) code catches redis.exceptions.RedisError to degrade. PR netbox-community/netbox#22481 (for netbox-community/netbox#21326) introduced the first instance: _flush() in netbox/search/deferred.py falls back to inline synchronous PostgreSQL indexing when the broker is unreachable. That fallback is correct for its case (the search index lives in Postgres, the originating write has already committed, so degrading avoids a 500 on a committed write), but it is unprecedented.

Decide a NetBox-wide stance, either:

• (a) Document a degradation pattern or helper that paths with a safe fallback can use, or
• (b) Accept that paths without a safe fallback propagate, and audit whether any user-facing path returns a 500 on a transient Redis blip when it shouldn't (e.g. webhook enqueue, dashboard worker count).

Justification

This is a convention and consistency question, not a bug. The local fallback in netbox-community/netbox#21326 is correct for its case; the gap is that we have no shared answer for the next path that hits the same decision. Without a documented stance, each new Redis-touching path picks refuse, propagate, or degrade ad hoc, and we have no baseline for deciding whether a transient Redis outage producing a user-facing 500 is acceptable. Noticed during review of netbox-community/netbox#21326.