Why is that?
Because when something is fixed in 3.8 while that is same issue was still present when 4.0 was forked the issue also is part of 4.0. Now, when fixed in 3.8 with this fixes release you do not expect the same issue to pop up again in 4.0 while in theory it might.
In theory, yes.
In practice nothing gets fixed directly in the fixes branch (unless it was introduced by some miracle only in that fixes branch / or had been unknowingly been fixed in main before).
So in 99.99% of all cases, a bug reported to any version will be fixed in the main branch (aka trunk). And then it will be merged.
Since the fixes 4 branch was created, any fix to main that would be merged to any fixes branch, would always also be merged to fixes-4.
So it is extremely unlikely that a fix gets merged to 3, but not to 4.
Mistakes do happen though. If they do, please point them out.
You can check the commits on fixes 3. The usually have "cherry picked from" remarks. You can then check that they are also present in fixes-4. And if not you can check if they should.
--EDIT
IIRC the following shows this
git log --cherry --oneline fixes_4..fixes_3_0
+ c6eba77be6 (HEAD -> fixes_3_0, origin/fixes_3_0) ide: updated res
+ a69f6e15ef docs: set version to 3.8
+ 57e899e4bb (tag: lazarus_3_8, build) updated makefiles
So the only commit that is on the fixes-3 branch (since the release of 3.6) is setting the version to 3.8, and updating the res file => now those are expected to be only there.