You're conflating the Software Development Life Cycle (SDLC) with accountability and responsibility. While there's some overlap among them, they are really three different things. You need to distinguish between those things in a way that makes sense for both your organization and your product development framework.
SDLC is a Set of Stages
In SDLC, who is responsible for ensuring that the backend API is compatible with the UI/UX?
There's no singular answer to this. SDLC—and yes, there are versions of SDLC that are iterative or incremental rather than linear—is a cradle to grave systems life cycle, so while you'll find plenty of useful information about the various stages of SDLC, you won't find a single RACI matrix or similar role chart that will hold true across every organization or even between all projects within a single organization.
Accountability vs. Responsibility
Even if you put together a RACI matrix, it's important to understand there's a huge difference between accountable (who must ensure something is done) and responsible (who performs the activities that get stuff done). Furthermore, most such matrices distinguish between many forms of collaboration beyond just accountability and responsibility.
In a non-agile organization, I'd say that the role most responsible for making sure you have a front-end that works with your back-end is the application architect. Without resorting to dictionary definitions, pragmatically speaking an architect is usually the role that designs the overall system and determines how the parts are intended to fit together. They don't do this alone, though; they often work with business analysts, end users, organizational stakeholders, and engineers to determine what the optimal solutions might be.
However, you also tagged your question agile without defining a specific framework. This prevents you from using a simplistic RACI matrix because most agile frameworks have the notion of "collective ownership" of the product being built. Consider that the Principles behind the Agile Manifesto says that "good design enhances agility" and that:
[D]evelopers must work together daily throughout the project...The best architectures, requirements, and designs emerge from self-organizing teams.
Analyzing Your Suggested Roles
So, none of the roles you named are really accountable, and by themselves are rarely responsible. In particular, testers are in no way likely to be either accountable or responsible, but are often collaborators in validating that the parts of the system are working to specification.
In an agile organization, the whole team is responsible for delivering incremental progress towards this product goal. In a more traditional organization, the project stakeholders (e.g. a project sponsor or steering committee) are ultimately accountable, although the project manager is often held accountable without the authority to do anything other than possibly influence outcomes.
While I certainly recommend the whole-team approach in an agile context, in any context I'd turn to the following skill sets (regardless of the organizational roles of the people who possess those particular skills) to be responsible for a design that works across layers:
Systems architecture skills.
Responsible for a design that works across layers.
Front-end and back-end skills.
Cross-functional skills among developers working together to build a solution that implements the design effectively between layers.
The ability to validate that the system is operating as intended.
In scrum or general agile approaches, the team is collectively responsible for delivering iterative or incremental slices together. This is not a fire-and-forget approach, though; it requires frequent inspection and adaptation by both stakeholders and the project team to ensure the final product is fit for purpose.