It appears that what you need are more branches. At least one for development and one for each released version.
The release branch would diverge whenever you make a major feature release. That release branch would then be used for hotfixes which you need to get online quickly, but which don't add any new features. Those would get merged back into the development branch as soon as feasible, but priority would be to ship them quickly.
You can do that while keeping the "trunk" workflow for working on the development branch. While the release branch is being used for hotfixes, the development branch would be the actual "trunk" on which all the new features get released. When you make a new feature release, you would merge any still remaining commits from the current release branch to the trunk and then create a new release branch for going through QA and deployment and which will then be used for supporting the new version post-release.
Should you transfer to a "flow-based" approach for development? That depends on how many features you are developing in parallel and how well you are able to plan and execute on your release schedule. When you have no problems with making all planned features complete before the release deadline, great. But when you frequently have situations where just before release some features are finished and some are not and delay the release, then you might want to switch to the "flow" model.
The flow model has the advantage that you are free to develop each feature in isolation on its own branch without polluting the main branch with half-finished stuff. When you want to make a new feature release, look at each feature-branch and decide whether or not it's ready to merge it into the main branch. Then do those merges, create a new release branch from the resulting main branch, and send the release branch down the QA and deployment pipeline.