I'm not sure what you mean, what does "tag a bugfix", "tag the bugfix branch" or "ensure the bugfix ends up in the remote main branch as well as the release" even mean?
What are you trying to achieve here, or what's the crux? I'm not 100% sure, but it seems you're asking about how to apply a bug fix while QA is testing a tag, that you'd like to be a part of the eventual release, but not on top of other features? Or is about something else?
I think one misconception I can see already, is that tags don't belong to branches, they're on commits. If you have branch A and branch B, with branch B having one extra commit and that commit has tag A, once you merge branch B into branch A, the tag is still pointing to the same commit, and the tag has nothing to do with branches at all. Not that you'd use this workflow for QA/releases, but should at least get the point across.
In that case one can just branch off a stable-x.y branch from the respective X.Y release tag as needed.
It really depends on the whole development workflow, but in my experience it was always easier and less hassle to develop on the main/master branch and create stable release or fix branch as needed. With that one also prioritizes on fixing on master first and cherry-pick that fix then directly to the stable branch with potential adaptions relevant for the potential older code state there.
With branching of stable branches as needed the git history gets less messy and stays more linear, making it easier to follow and feels more like a "only pay for what you actually use" model.
"with potential adaptions relevant for the potential older code state there"
And there it is. Not "potential adaptations", they will be a 100% necessity for some applications. There are industries outside webdev where the ideals of semver ("we do NOT break userland", "we do NOT break existing customer workflows", https://xkcd.com/1172/) are strongly applied and cherry-picking backports is not a simple process. Especially with the pace of development that TBD/develop-on-main usually implies, the "potential older code state" is a matter of fact, and eliding the backport process into "just cherry-pick it" as you did is simply not viable.
At work, we do what I wrote frequently, and it works very well and adaptions are rather the outlier than the norm, especially as we focus on backporting only important bug fixes and especially security fixes. We do also pour quite a bit of effort into separating changes into actual sensible commits (not just PRs), which is a bit of work but pays off dramatically if one has older releases they want to provide security and (grave) bug fix support.
I.e., this is not just some random thought experiment, my staff and I successfully employ this approach for well over a decade (and about another decade before my time at the company).
Sure, not all workflows are a good fit for this, that's why I started with a disclaimer. But, if you want to do stable release in general, then it's IMO better to adapt the general workflow to that (which provides other benefits too, like on bisecting or when writing actually good release notes), than trying to force that on a not so compatible workflow.
But I'd be happy to hear alternatives, like how you solve this; always interesting to read others perspectives that lay out their solutions (not just why mine doesn't work 1:1 for you, which is basically a given for any non-trivial project).
Not sure I need to give any example solutions, because you've already explained that your solution isn't great, "mine doesn't work 1:1 for you, which is basically a given for any non-trivial project", and that applies for most solutions. But I will:
* GitFlow isn't perfect, but works for many, especially projects with lots of contributors working concurrently, and double especially if there are release gates that keep a human (release engineers) in the CI/CD loop for accountability, which is not uncommon in real world commercial projects.
* GitHubFlow works for lots, but not all. Pretty good for moderate team sizes with some but not so much concurrent overlapping work, and perhaps a dedicated release engineer to handle those "potential adaptations".
* TBD works for some, but can be inappropriate for many, especially when there are long-lived stable branches with commitments to ongoing security and bugfixes and the team size is smaller such that dedicated release engineers are not a thing.
This list is obviously not comprehensive, and just pulls from some workflows commonly presented elsewhere in this post.
Basically, I was just saying that one _can't_ just "[fix] on master first and cherry-pick that fix then directly to the stable branch with potential adaptions", because in most projects (non-trivial, as you said, which probably means anything with more than a couple contributors and an actual concept of a "stable branch") there will always be adaptations that need to be considered to maintain the stableness of that stable branch. And that's stableness from the user/customer/client PoV of "it acts the same but with less undefined behavior [read: bugs]", not just the dev PoV of "tests pass and it doesn't crash".
Usually what I've seen is one of two solutions, the former (usually) being slightly favored: A) hide any new feature behind feature flags, separate "what's in the code" from "how the application works" essentially or B) have two branches, one for development (master) and one for production. The production branch is what QA and releasers work with, master is what developers work with, cherry-picking stuff and backporting becomes relatively trivial.
We've been using feature flags but mostly for controlling when things get released. But feature flags carry their own issues, they complicate the code, introduce parallel code paths, and if not maintained properly it gets difficult to introduce new features and have everything working together seamlessly. Usually you want to remove the flag soon after release, otherwise it festers. The production branch is also ok, but committing out of order can break references if commits are not in the same order as master, and patching something directly to prod can cause issues with promoting changes from master to prod, it requires some foresight to not break builds.
With (B) you've just reconstructed the part of git-flow that was questioned at the start of this thread. Just switch the two branches from master/production to develop/master.
The second one you described is basically GitFlow, just substitute "master branch" for "production branch" and "dev branch" for "master branch". I mean, you literally said "master is what developers work with", so why not call it the "development branch"?
What are you trying to achieve here, or what's the crux? I'm not 100% sure, but it seems you're asking about how to apply a bug fix while QA is testing a tag, that you'd like to be a part of the eventual release, but not on top of other features? Or is about something else?
I think one misconception I can see already, is that tags don't belong to branches, they're on commits. If you have branch A and branch B, with branch B having one extra commit and that commit has tag A, once you merge branch B into branch A, the tag is still pointing to the same commit, and the tag has nothing to do with branches at all. Not that you'd use this workflow for QA/releases, but should at least get the point across.