Scrum/Agile/Budget

Let's break the first part down:

• When should I, for example, define code standards?

If your organization has code standards, you would start there. If there are none, this would be defined by your entire Development Team. This would all be part of your Definition of "Done", and completed before you start Sprinting. Otherwise how would your team know how much work they can do in the first Sprint, and how would anyone know the work is Done (potentially releasable.

• braching strategy on git? or set up the server and CI / CD tools? Before sprint 1? or in sprint 1 as user stories?

This work would be taken on in your first Sprint (at least started to get the team up and running. Also it would be important to deliver at least one small feature that your customer wants, they're paying the bills. This will keep them interested, and your Scrum Team can validate how CI/CD is working.

User Stories are optional in Scrum, and a way to describe your Product Backlog items. I would not recommend user stories for the tooling (CI/CD, github setup), keep it simple. But do have Product Backlog items for these in your Product Backlog.

Hope this first part helps.

Does the product have a subscription model? If so, the client is paying you as long as you provide value to them. Once that ceases, they will find another product. Continued innovation is built into your contractual obligations, whether or not it is explicitly stated. Otherwise, it's just a maintenance service.

Going to take a slightly different path.  

First, you do none of the things you asked.  The Scrum Team does all of them.  There is no one that does all of those things unless the team decides that person will do it.  And typically a team will look to the organization to see if there are standards in place, especially for source code management and client billing.  Most companies will already have policies in place for both. 

If a team has not used Scrum before and is just starting up, there is nothing in Scrum to say how or what is to be done before the first Sprint other than having a Product Backlog in place.  The Sprint is an event with a purpose of delivering a potentially releasable increment of value to stakeholders.  Set up of source code systems, defining of contracts and billing are usually not seen as value by stakeholders so do all of that while you are also building up your Product Backlog to a point where you have enough items defined to start building and delivering value. 

Scrum is used to deliver value to stakeholders via work done by a Scrum Team. All of the things you stated delivers value to the organization and Scrum Team so you can do that at any time.  

hello, jaine C  I will clear your doubts 

Define code standards, branching strategy, and set up server/CI/CD tools ideally before Sprint 1, but if essential for Sprint 1 tasks, include them in that sprint's backlog.

Consider a pay-per-sprint contract for charging the customer, providing transparency and flexibility.

Discuss payment terms with the customer - payment at the beginning or end of each sprint can work, and regular communication ensures alignment.