I like the reasoning you have (all of you), but I don't think they follow how the matrix rules are written. Maybe we are trying too hard thinking about how it worked back in 2019 and a bit too little of how the rules are actually written?
The Jam Signals Matrix Action does not only affect matrix actions conducted on devices that are inside the area of effect (like jammers do). Unlike jammers it explicitly also affect matrix actions that originate from devices outside the area of effect but are targeting devices inside the area of effect:
SR6 p. 182 Jam Signals
This action turns the wireless device you are using into a local jammer. As long as you do not use the device for any further Matrix actions, the device adds any hits you get on the test to the noise rating for all Matrix actions conducted by or targeting any devices within 100 meters.
(emphasis mine)
Unlike Jam Signals, the author for Jammer clearly choose to use another wording. A specific sentence with an explicit wording that make it clear that it only affect devices inside the area of effect were added:
SR6 p. 270 Jammer
The jammer only affects devices that are within the jamming area, but it affects all of them.
(emphasis mine)
Would it make sense if Jammer also affected matrix actions that are aimed at devices inside the area of effect? I personally think so (and so do a lot of the rest of you in this tread it seems), but the author here seem to have good reason why it should only affect devices inside the area of effect.
Either we respect what is written or we house rule that it work in a different way (that is what house rules are for after all), but I don't think one should claim that affecting matrix actions taken from devices that are clearly outside the area effect to be 'RAW' (because it isn't).
In regard to electromagnetic jamming signals in SR6 specifically it seem as if you just need to have a good connection to the "matrix" and then the "matrix" (rather than your device) will take care of transporting the signal all the way to the final target (maybe because the matrix is using a mesh network topology or whatnot). It seem as if as long as (three 'as' in a row, is that even legal??) your device have a good enough signal strength to still be connected to the matrix then it doesn't really matter how much electromagnetic jamming signals there are at the target device. It seem as if conditions at the target device will not directly affect you and your tests (unless, of course, conditions at the target device are so bad that they knock the device off-line in which case you cannot take any matrix action against until it resurface somewhere in the matrix).
If my cyberdeck is not inside the area of effect of your jammer then my cyberdeck is not affected and it is not at risk of being knocked off the matrix due to poor signal strength.
If your drone is at my physical location and not inside the area of effect of your jammer then your drone is also not affected and it is not at risk of being knocked off the matrix due to poor signal strength.
But if your RCC is inside the area of effect of your jammer then your RCC is affected and is at risk of being knocked off the matrix due to poor signal strength.
If I am trying to Data Spike your RCC then my cyberdeck will have a perfectly good signal to the matrix and I will only be affected by noise due to physical distance.
If you are trying to remote control your drone at my physical location your RCC will be affected by the jammer and you will have a poor signal to the matrix and your piloting and engineering tests will be both affected by local noise conditions generated by the jammer as well as noise due to physical distance.
If I am trying to gain User Access on your PAN rather than Data Spiking your RCC specifically then I could instead target your drone. Since your drone is part of your PAN and very close to my physical location I will in this case not even suffer noise due to physical distance (this is one of the drawbacks of having a large PANs that is also spread out over a huge physical area).
If you put your RCC on the jammer's white-list then my cyberdeck will still have a perfectly good signal to the matrix and I will still only be affected by noise due to physical distance when Data Spiking your RCC and I will not be affected by physical distance if I target your drone or your PAN via your drone that is part of your PAN, but in this case your RCC will no longer be affected by noise from the jammer so when remote controlling your drone at my physical location your piloting and engineering tests will only be affected by noise due to physical distance.
I can't see many other ways of resolving this without house ruling that jammers would, in addition to only affecting devices that are physically inside its area of effect, also affect devices outside the area of effect if they are trying to take specific actions on (or against) devices that are physically inside the area of effect.