Some frameworks have a distinct name for the type of work you're asking about, but some don't. To understand why, a short preface is in order.
Work is work. While it's sometimes necessary to differentiate different types of work for cost-accounting or political reasons, treat this as an opportunity to educate your organization and your stakeholders that there's no such thing as a free lunch. In agile frameworks, all work should be fully visible as a cost to the project.
There may also be a more fundamental concern than differentiating types of work. The scale of upfront architectural and infrastructure work in your diagram suggests that you may be violating a core agile principle:
Simplicity--the art of maximizing the amount of work not done--is essential.
Your team and your organization should certainly evaluate the minimum amount of planning, infrastructure, and engineering (collectively resources) necessary to carry out the near-term increments. In a successful agile implementation, your infrastructure and design will evolve iteratively along with your product.
Don't Overly Constraint Your Definition of "Value"
In general, effective agile implementations don't separate out user-facing value from work that's valuable (and frequently essential) to the process as a whole. The idea that all "value" must be customer-facing value is not correct.
In the most commonly-used user story format, the who in the story is a consumer of value, but that viewpoint character need not be an end user or customer, and the value may be anything that the Product Owner, sponsor, or stakeholders are willing to spend project resources on.
That said, the goal is to avoid "big, upfront design." So, a logical question to ask during each planning session is: What are the mininum resources or architectural/technical choices necessary to deliver a slice of value this iteration?
SAFe, Architectural Runway, and Enablers
SAFe calls this minimum necessary infrastructure the architectural runway.
The Architectural Runway consists of the existing code, components, and technical infrastructure needed to implement near-term features without excessive redesign and delay....Since the development of new features and capabilities consumes the architectural runway, continual investment must be made to extend it by implementing Enablers.
It further explains Enablers this way:
Enablers support the activities needed to extend the Architectural Runway to provide future business functionality. These include exploration, infrastructure, compliance, and architecture development...Primarily, enablers are used for exploration, evolving the architecture, Compliance, and to improve the infrastructure.
However, this is not permission to dive into big, upfront design and infrastructure investment. SAFe, like most agile frameworks, is based on principles of emergent design and just-in-time architecture, and delays investment in infrastructure until the last responsible moment. This is sometimes referred to as YAGNI.
But Enablers aren't really a special kind of work, even though SAFe insists on giving it a special name.
[Since Enablers] reflect the real work (and sometimes plenty of it), they cannot remain invisible. Rather, they’re treated like all other value-added development activities—subject to estimating, visibility and tracking, Work in Process (WIP) limits, feedback, and presentation of results.
In short, such tasks are value-added work that should be treated just like any other work necessary to develop the increment during an iteration. SAFe spills a lot of ink unpacking this concept, while other frameworks tuck it away in the notion of "vertical slices" or just-in-time resource planning.