When a sketch is running, the AVR microcontroller and the Linux system talk to each other over the Serial1 port using the Bridge library. The SPI port is not used unless you have explicitly written code on both the AVR and Linux sides to enable it and use it.
When loading code over the USB port, the Arduino IDE builds a hex image of the sketch that does not include the serial bootloader. The AVR processor is then reset so that it enters the bootloader, and the sketch is downloaded to the AVR processor using the bootloader that is running on the AVR processor. In this way, the bootloader space remains unchanged, and only the portion of the program flash that holds the sketch is updated.
When loading code over the network, either through the Luci web interface, or directly from the IDE, things are a bit different. The IDE still builds a hex image of the sketch without the bootloader, and that hex image is transferred to the Linux system (either directly by the IDE, or manually through the Luci web pages.) The Linux system then combines the sketch's HEX image with the bootloader image, and then uses the SPI interface to load the entire program flash space including the bootloader and sketch. In this way, the Linux system acts like an ICSP loader pod. While this is happening, the Linux system is a SPI master, and the AVR microcontroller is a slave (although no sketch is running at this time, just as no bootloader is running.)
The SPI link between the Linux and AVR processors is normally deactivated so that the signals are isolated. When the Linux system is loading code, it asserts GPIO21, which enables the U5 level shifter chip. This connects the SS/MOSI/MISO/SCK lines on the AVR processor to GPIO26/GPIO27/GPIO8/GPIO11 on the Linux processor. The Linux processor then bit-bangs the SPI interface and loads the code. When done, the Linux processor de-asserts GPIO21, and the two systems are once again isolated.
If you have circuitry connected to the ICSP header on your Yun so that the sketch can use the SPI interface (as either master or slave) then you must take care that the circuit does not try to drive any of the SPI signals. The Linux processor must be free to drive the SS, MOSI, and SCK lines without interference, just as the AVR processor must be free to drive the MISO line without interference.
This is typically not an issue as long as the external SPI hardware is properly set up for a multi-device SPI interface. In other words, the slave device(s) never drives the lines unless it is selected, and when not selected, all lines are high impedance (inputs are normally high impedance, outputs will need to enter a tri-state condition.) The external hardware should only drive lines when its chip select input is active. Since the Linux processor drives the SS signal while loading code, you should not use the SS signal as the chip select signal for any SPI slave device, or it will be selected during the programming operation and interfere with loading code.