Suggestion: please make documentation (both in-line and of the whole solution) an important decider for the competition. Clever hacks are cool, but if the goal is to expose people to FPGA design, cryptic code on its own will hardly help.

You can do this without a keyboard or mouse even, but it's a bit more tricky.
First, before you boot your RPi, create an emtpy file called 'ssh' in the boot folder of the SD card, e.g. on the same machine that you used to write the card.

Now when the pi boots, it will have SSH enabled so you can log in. NOTE: this will be with the default raspbian username and password, so you should change the password as soon as possible. Otherwise, you'll RPi gets hacked and abused.

Now to find the IP address on the pi, let's first assume that you are using an Ethernet cable, as your Pi won't yet know how to connect to your WIFI. You can e.g. go into the LAN settings for your router, which might list all the IP addresses it gave out. Or you can see if your router has added a hostname 'raspberry' to your network. Another option is to use tcpdump, and to look for a mac address that starts with b8:27:eb. You can also from your linux machine type 'arp -an' and see for an entry that matches it.

UDP is generally a great way to get your data into or out of an FPGA. The Zybo Z7 already has Gb/s Ethernet on board, which you should be able to access from either the FPGA logic, or the ARM cores. Given the low data rate that you are quoting, your best solution might be to put a small Linux on the ARM cores, with a driver to talk to your logic. From the Linux side, you can then send/receive the data, either as UDP or even as TCP if you want.

If getting Linux running on it seems overkill, the other approach would be to simply drive your Ethernet port directly from the logic resources in the Zynq. UDP on IPv4 is really easy because you don't need to calculate the UDP checksum (just leave it at zero). Apart from the content and CRC32, every other part (preamble, headers etc.) can be the same for every packet. In my experience, calculating the CRC32 at 1Gb/s does require a pipelined CRC calculation, but on the much older Spartan3A-DSP1800, I could do it in only 2 stages.

With modern switches, you can often read out the received optical power to the SFP. From the other end of the link, you should be able to read out the optical power being put onto the fibre. This way, you can see how much loss there is, and whether the signal at each of the SFPs is well above the RX sensitivity limits, without any extra equipment needed. This does require the SFPs to support DOM (Digital Optical Monitoring), but quite a few of them do.

Some issue: during startup, you get a popup 'hl2.exe has stopped responding'. When I join a map, it often happens that moving my mouse causes sideways motion, instead of turning (bit hard to get out of spawn that way!)
In general, things seem to stutter quite a bit.

Are other people seeing similar issues? Might this be due to e.g. recent Meltdown/Spectre patches?

Given your requirements, you could consider buying a software defined radio (SDR). The Ettus X300 or X310 might fight your need, with a cheap ADC and DAC board. You can for instance buy a LFRX/LFTX ADC/DAC daughterboards, which give you 30MS/s and work all the way down to DC.

The challenge might be to get your filtering code to live on the FPGA, although that's certainly doable, and with RFNoC you might even do that from within GnuRadio, while all the processing happens on the FPGA.

Note that Ettus was bought by NI a few years ago. There is also a tool called LabView Communications System Design Suite that might allow an even easier integration, but I'm not familiar with that at all.

Given that you only need a small number of ports, have a look at the Mellanox SN2100 half-size switch with 16 ports 100G. Also available with Cumulus, which I'd recommend. Using Cumulus also has the advantage that all SFPs are accepted, so you don't have to deal with the usual vendor shenanigans.