Something that Scrum (and even Nexus) doesn't do well is project inception. Project inception includes things like team formation, project vision, organizational direction, initial scope, creation of the work environment, technical strategy, and risk management. Instead, Scrum is focused on construction activities - choosing what to work on now, working toward a solution, and addressing changing needs throughout the project. Both the Scaled Agile Framework (SAFe) and Disciplined Agile Delivery (DAD) address these activities in an agile context.
Now, SAFe and DAD are designed for use in an enterprise, with multiple agile teams working in coordination with each other to deliver products. If you have a single team, they may be overkill, but you can learn about what they have to say and apply portions of it to your environment.
Some of the things that you are concerned about - choosing hardware and software architecture and security, for example - are part of a technical strategy. In Scaled Agile Framework, there are System Architects and Release Train Engineers (at the Program or Value Stream level, working across development teams) and Value Stream Engineers (at the Value Stream level) who are focused on these cross-cutting technical involvement. In Disciplined Agile Delivery, there is the role of an Architecture Owner to own these decisions. Still, they may make them as a group with other members of the organization or team. In both of these scaled frameworks, these people begin creating the initial backlog that goes to development teams early in the project.
Some of your other concerns, such as database design and user roles and permissions, will come from the design and implementation of features. They will come from business requirements that are prioritized by Product Owner (in Scrum or DAD) or Solution Management, Product Management, and Product Owner (in SAFe). You can perform iterative and incremental database design, and there are other resources (including questions here) about that.
Yes - you should be doing some level of up-front work to establish your architecture and development environment before you begin your delivery iterations or sprints. The amount of detail depends on how much risk you are willing to accept. If you need to capture a formal system specification, that depends on your requirements for configuration management. In a regulated industry, you should have documented and consistent policies regarding development, test, and production environments and tools. In other sectors, it may not be necessary. Scrum, as a framework, doesn't specify how you do this, so you'll need to look at other process models.
As far as if your backlog is a good one, work with your team. Is it good enough for them to estimate? Is each item reasonably scoped and can be broken down into subtasks and then executed by the team? Only they can answer those questions.
