I had the pleasure of consulting with James on this topic when we introduced session based testing in my company. If I recall correctly he initially only used it to check that the session report was done in accordance with the required format so the tool could extract the information needed to generate the needed report for management. Occasionally he also used it to reject sessions saying that the coverage of the testing was not sufficient for that charter to be considered completed. That was only applicable if the tester was junior and needed some pointers. And it resulted in the tester doing the another session on the same charter.
Right now we use it more as a peer review (similar to the review process for pull requests and code) where you can look more towards the knowledge transfer aspects. Both in terms of how you do testing of a specific thing as well as between the testers (we are two for each project) to sync what have been done and not. For me not the most valuable use of our time.
As for your question regarding the bugs I have always raised them as part of the session. One time we added time it took to report bugs as a metric to investigate is we needed to speed up that process or not. At the time most of the time went to deal with test environment and test data (i.e. time not spent testing) so speeding up the bug process was not a concern of ours.
If you, like me, work in iterative environments where you plan and release every two weeks I would suggest you have a look at thread based test management instead since I have found that to be easier in those environments.