API cache decorator mishandles method, auth, and streaming cases

## Describe the bug

The existing API cache decorator does not correctly handle several edge cases, which can lead to incorrect caching behavior and potential data exposure. Specifically, the current implementation assumes a function-based view signature, does not differentiate cache keys by HTTP method, may cache authenticated user responses, and does not guard against streaming responses or cache backend failures.

These behaviors can result in incorrect responses being served from cache or unintended caching of sensitive data.

---

## To Reproduce

1. Apply the existing `cache_response` decorator to an API endpoint.
2. Perform both `GET` and `HEAD` requests to the same endpoint.
3. Access the same endpoint as both an authenticated and unauthenticated user.
4. Return a `StreamingHttpResponse` or simulate a cache backend exception.
5. Observe cached responses being reused incorrectly or cache errors affecting request handling.

---

## Expected behavior

* Cache keys should safely distinguish requests by HTTP method (e.g. `GET` vs `HEAD`).
* Authenticated user responses should not be cached by default.
* Streaming responses should never be cached.
* Cache backend failures should fail open and not break request handling.
* The decorator should work correctly for both function-based views and bound methods.
* The decorator should safely no-op when no `HttpRequest` is present.

---

## Are you going to work on fixing this?

* [x] Yes
* [ ] No

(A working patch and extended test coverage already exist and can be proposed if this approach is approved.)

---

## Screenshots

Not applicable.

---

## Desktop

* OS: Linux (Fedora - 43)
* Browser: Firefox
* Version: Latest

---

## Smartphone

Not applicable.

---

## Additional context

A revised implementation was validated locally with extended unit tests, raising `apps/api/decorators/cache.py` file-level coverage to **100%**, while preserving backward compatibility.

The changes focus on correctness, safety, and robustness rather than introducing new features. If the maintainers agree with this direction, a focused pull request can be opened referencing this issue.