It's worth noting that architecture and requirements emerge throughout a project. Emergence of requirements is a focal point of empiricism. Architecture should be negotiated based upon what you can build this sprint that will provide value to your stakeholders. If you need all of this in order to meet your sprint goal, then that should be conveyed to stakeholders in a transparent manner. Using your product and sprint backlogs to drive the conversation and convey these dependencies is a good place to start as they are clear visualizations of what you need to meet your goal.

To answer your question: those are simply dependencies your team needs to meet their sprint goal, assuming your sprint goal is to be ready for release 1 by the end of the sprint. If your sprint goal is something other than to be ready for release 1, then it's possible the work can be broken up, thus breaking up the need for all those upfront dependencies until they're needed to meet a sprint goal.

It's worth noting that architecture and requirements emerge throughout a project. Emergence of requirements is a focal point of empiricism. Architecture should be negotiated and designed during planning and refinement based upon what you can build this sprint that will provide value to your stakeholders. If you need all of this in order to meet your sprint goal, then that should be conveyed to stakeholders in a transparent manner. Using your product and sprint backlogs to drive the conversation and convey these dependencies is a good place to start as they are clear visualizations of what you need to meet your goal.

To answer your question: those are simply dependencies your team needs to meet their sprint goal, assuming your sprint goal is to be ready for release 1 by the end of the sprint. If your sprint goal is something other than to be ready for release 1, then it's possible the work can be broken up, thus breaking up the need for all those upfront dependencies until they're needed to meet a sprint goal.