I don't know of an internal feedback tool, that's not more general purpose. I think a lot of what you're describing is the-practice-of-software-development. There are Lots of possible solutions, what works best for _your_ team will be somewhat unique to them.

The company I work for [0] provides application hosting which includes automatic preview URLs, that can also be associated with a Github PR. The PR will have a link to the environment, with discussion below. Subsequent releases to the environment also get registered with the PR so it's easy to catalogue and annotate developments/fixes.

0. https://noop.dev

If you deploy on Vercel, the preview builds are automatic, and there is on-page commenting and discussions: https://vercel.com/docs/workflow-collaboration/comments

There are similar tools if you're not on Vercel, like https://usersnap.com/l/visual-feedback-tool

But beyond that, I don't think you should be having all the long discussions in the same place that you keep your tickets (let's say a kanban board). Have your discussions wherever you want, but keep them between the 2-3 people really involved. Then once they have an idea of what needs to change, THEN they can make a ticket for it with just some simple bullet points (linking back to the full discussion if they want).

Having everyone comment in the QA ticket directly mixes up discussion about the ticket itself and discussion about what to ticketize (which should've been done previously, outside the ticket). It's too much detail for the rest of the team to keep up with. They don't need the whole sordid history of how you got there, just what needs to be done.

In the teams I've been on, that previous discussion would happen all over the place... sometimes over Slack, sometimes over coffee at the coffee shop next door, sometimes in Figma/GDocs/Vercel comments, whatever. But once we come to an agreement, one of us writes the actual ticket without all the baggage, keeping it simple and clear.

----------

Edit: I think it really helps to have someone on the team who cares a lot about organization (and maybe even enjoys it). That could be anyone... a manager, project/product owner, one of the devs with a lighter workload, etc., just somebody who's OK going through the tickets once a week or so and making sure they have sufficient information for working on, and pinging the individual ticket creators for clarification if needed. The rest of the team doesn't need to get involved, but it helps make sure that the tickets are ready for work once you get to them. THAT's the sort of stuff that the comments in the actual ticket are good for (clarifications, not brainstorming).