Not 100% on the design, but when it says "synthe unlocked" have you been able to correlate signals internally that are obviously out of place?
If that block diagram you've made is right, I can imagine three potential causes of such an error message:
The base synthesizer output is varying when it shouldn't be
The YIG isn't able to lock to the synthesizer
The fixed 4G oscillator isn't stable
If your 4GHz fixed LO is looking ok (and if the lock is intermittent but works on some ranges, I think this would work), and your primary synthesizer locked to the 10MHz reference is outputting steadily (again, if this is supposed to be fixed and works for some frequencies, I would assume this s alright), then the problem would be with the YIG. This could be the oscillator itself or it could be the amplification out of it (need relatively high output for the next stage mixing, maybe some frequencies are below what's needed) or that something about the driver circuitry isn't able to adjust properly to lock to the synthesizer's reference (the YIG has its own PLL).
So I'd check the output of the synthesizer block and then the input and output of the source block to try and figure out what exactly (module level) is up with the synthesizer. Then you can start tracing out the signal on the board and identifying functional blocks. If it is indeed YIG or PLL related, you'd be able to see abnormalities in the drive circuitry, or in the frequency division in the PLL or similar, and if it is power related, narrowing it down to what board will let you monitor the rails for just that module, so if you feel like just replacing caps en-masse, at least you only do it for a rail or two in one module.
For understanding troubleshooting methodology in this kind of equipment, I'd also recommend TheSignalPath on youtube, as Shahriar has done some repairs for SAs/VNAs/SGs that use use somewhat similar architectures to generate their RF signals, so you can get a feel for the layout of the boards, the architecture of the unit, or just some common problems these units can run into if you aren't already familiar with it.
There are a lot of potential problems, but with a fairly generic error message, I think the priority should be trying to isolate the particular module that is causing the issue - it could potentially be more than one, but I think more often than not a single failure is the thing to bring down the beast unless it's some sort of overload condition.
As for the floppy, may be tricky to find but if a physical service manual turns up it's the kind of thing that could be in an appendix or in a pocket of the binder. Just from the name, Source_Correction.Basic may give an outline of what's in there if it needed to be reconstructed... but it would likely be a very tedious task. It could be worth looking in calibration files stored on the drive (or in eeprom?) for values, because I assume that file probably just prompts a cal lab tech to enter levels from a power meter so it makes its own calibration curve (though it could be that the basic code generates the coefficients, and only those are stored for calibration).