The Scrum Master is not part of the Development Team. Your assessment is correct - the term "Scrum Team" refers to the Scrum Master, Product Owner, and Development Team. The Development Team includes all of the people who are doing the work to transform Product Backlog Items into a potentially releasable Increment at least at the end of a Sprint.
If the Scrum Master is doing work toward the potentially releasable Increment, then the Scrum Master is also on the Development Team. The person with the role of Scrum Master also has a role of Development Team member.
It sounds like part of the confusion is between the Product Backlog and the Sprint Backlog.
The Product Backlog is a list of "all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases" (from the Scrum Guide). Each of these individual items on the list are Product Backlog Items. The Product Owner is responsible for the Product Backlog.
Product Backlog Items are refined by the Scrum Team. The Product Owner and Development Team collaborate on the process of refinement. The Development Team makes sure that each Product Backlog Item has enough information to implement and any details or questions are addressed. The Development Team also provides an estimate to aid the Product Owner in ordering the Product Backlog and understanding when work may be completed.
In Sprint Planning, one of the outputs is the Sprint Backlog. The Sprint Backlog starts as a set of Product Backlog Items that were planned for the Sprint. However, there may be discrete elements of work that the Development Team identifies in planning. These items are also added, by the Development Team, to the Sprint Backlog. Throughout the Sprint, the Development Team is responsible for maintaining the Sprint Backlog.
These Sprint Backlog Items (my term - not something found in the Scrum Guide) aren't estimated. They are simply things to support transparency. By breaking down the work into more fine grained elements, the Development Team gives the Product Owner and themselves more visibility into the work being done in the Sprint. The idea of putting these work items into the Sprint Backlog is to ensure that the team knows what work is required, help people to focus on work that needs to be done, and to identify if there are threats to achieving the Sprint Goal.
The Development Team should be the one creating Sprint Backlog Items, at least at a conceptual level. However, that doesn't necessarily mean that the Development Team will create the Sprint Backlog Items in a ticket tracking tool. Perhaps the Scrum Master will do that. Just like how the Product Owner can delegate some work, the Development Team can also. Perhaps it makes sense that, if a ticket tracking tool is used, the Scrum Master may be asked to enter the work there. One of the responsibilities of the Scrum Master is to facilitate Scrum events, and ensuring that work is appropriately entered into the ticket tracking tool facilitates the refinement of Product Backlog Items as well as Sprint Planning and perhaps Sprint Review and Retrospective as well.
A question for you: As Scrum Master, are you facilitating the team by removing the concern of entering work into a tracking tool? Or are you entering work with the intent of instructing the team on how to turn Product Backlog Items into a potentially releasable Increment? One is consistent with the principles of Scrum. The other is not.