Sorry for joining the discussion a bit late.
First, I’d like to thank you for those efforts and really looking into the core packages w.r.t. licenses 
This is an issue for quite a number of companies that would like to use ROS but are “afraid” of the effort of using open source “the right way” might bring (granted, there are many that don’t care at all 
).
As to your question: i think that for the current state of ROS 1, I’d go for adding the reports to the respective branches.
Rationale: ROS 1 will be EOL in 2025, the number of (actively supported) branches will decrease the more ROS 1 distros will reach EOL (effectively, in less then a year we will be down to two).
If the clearing (with Fossology) will be done at, say, every release, the manual effort will be minimal, I guess. I.e., if the repository is rescanned and all prior clearing information is kept. But it would still need to be done.
All in all, I think the ship has pretty much sailed for ROS 1 to get this done consistently. Though any efforts for making this easier (and maybe establishing a base line for ROS 2) are still very worthwhile!
I think this is totally different for ROS 2 though. Probably this would be a good spot now to start a discussion about how this could properly be done “early on” (I realize that “early” is rather “before widespread adoption” than actually “early in the project”).
One thing that could be worthwhile is to define a few best practices about how to specify licensing and copyright information more clearly in ROS packages to begin with.
I’d propose to start with making all core packages REUSE compliant. This is something that e.g. the linux kernel has done. Also, this largely simplifies any further scans and allows direct creation of spdx reports. Additionally, one can integrate checks for reuse compliance with CI/CD. And you could even add badges to the READMEs.
Then again, this is just a proposal and there are probably quite a few other ways to go.
At the end, one small comment about semantics:
I would try to avoid calling this “license clearing information” (even with “(clearing)” in brackets), as clearing is always linked to an existing policy. And this might differ from company to company quite a lot. License A might be totally fine for company X whereas it is a total no-go for company Y.
I’d go with “licensing information” or “licensing definitions” or something similar.
