Create Composite backend for non-prod curriculum API testing

[marcellamaki]

Summary

This PR introduces a CompositeBackend that accepts a backend and a list of url_prefixes to manage optional unstable backend connections in non-production settings.

It also adds a test, and updates some existing tests that are testing prod-only scenarios to clarify that they are production only and do not use the composite backend.

References

Fixes #5584

Reviewer guidance

I leaned heavily on Claude to understand this area of the code base but used it more as a tool to investigate and orient myself, as well as practice some of the patterns. I wrote the code myself (although it did point out more than one error in my python syntax 😁 ), with the exception of updating the existing tests in test_recommendations.py (which I didn't think to do on my own).

I do have some questions about my approach, so I opened this as a draft PR to have a reference for what I was wondering about. I've intentionally left two separate commits so they can be compared.

In the first commit, I have an initial implementation of CompositeBackend that:

accepts a list of backends in its constructor

I continued from there, but after writing tests for the first time, I realized (after reviewing the error message with Claude) that I wasn't able to create multiple backend instances.

In the second commit, you will see a different approach, which passes one backend, and a list of prefixes and the rest of my changes. It seems to still meet the same goals of the acceptance criteria. Is this second option better?

I did a bit of brainstorming with Claude about other possibilities and googled a bit about the "singleton pattern" (new to me!) but moving away from that seemed like there could potentially be other unforeseen consequences. And I don't feel confident in my ability to know what those might be :)

Look forward to thoughts!