I'll skip over the whole issue of how agile should be about letting teams be free to modify their internal processes to find something that works efficiently for them, since other answers have covered that.
Does your scrum board software allow for sub-tasks within each story that aren't shown on the main board (only visible within these ticket for each story)? Of so you could try creating tasks for each stage : coding, writing unit tests, QA/ manual testing, code review, merged to master). Each task can be marked as done when completed, and anyone looking at the story ticket can easily see which tasks are still to do before the whole story can be closed. Meanwhile the actual team scrum board still shows what it did before.
But that's just trying to find a workaround acceptable to the basic fact that a) your scrum master is trying to dictate how the developers organise their work and b) puts more priority on making infromation visible to management than on getting production work done properly. Ideally the solution would be to convince your scrum master that imperfect management information of effective work trumps perfect management information of poor work. The problem is that management often don't see it that way, so your scrum master's performance reviews, KPIs and bonuses may incentivize exactly what you are seeing. On a practical level, asking your scrum manager to hurt themselves financially and career wise to make your life easier obviously isn't going to work.
In which case you need to stop seeing the scrum master as the problem and make them part of the solution. Explain to them the difficulty the current system creates in terms of important work getting overlooked because the team can't adequately keep track of it. Ask them for their help and suggestions for finding a solution. Listen to them and understand the constraints they are working under that might not be apparent to you (or might be completely idiotic and imposed from above, but you have to deal with reality as it is, not as you'd like it to be). Ask what you can do to make their job easier. Emphasise that you want to find a solution that works for them as well as you. Surprisingly often, just taking the time to understand their point of view and empathise with them will make the problem go away. Or the discussion will point the way to a mutually improved solution. I guarantee that your scrum master is operating under at least one important constraint (whether externally imposed or due to internal motivations) that you are oblivious to.
It may be a cliche, but "'No' isn't the end of the discussion, it's the start of the negotiation". Coming along with your own solution out of the gate that hurts them isn't negotiating. Going to them with "This is the problem that exists, and we'd like your help in figuring out a good solution" is the start of a negotiation.
