You have misread the schematic which you linked.
The part you have circled is actually U2, the debug interface comprised of an additional MCU, with its own clock circuit, while U1 is the target MCU placed in diagonal orientation in the middle which runs your program.
While some similar boards save a little money by feeding a clock output from the debug MCU to the target, the schematic you linked shows that yours does not.
Rather, on your board, the target U1 is clocked from its own external 16 MHz crystal, or a lower frequency watch crystal, or likely internal oscillators, likely starting from the latter and then shifting to another option under software control. More importantly, in common usage it would actually not be directly clocked by these, but rather by the output of an internal PLL multiplier configured by your code.
Generally speaking, if you perform the right configuration options (ie using a vendor library) and do not do something unexpected (like call the configuration routine when it is already running on the PLL) these "just work" and you typically would verify that they are operating by reading status bits with software.
If you really wanted to look at the external clock frequency with a scope, try probing C32 or maybe C31 with a 10x probe to minimize disruption of the circuit. Generally though it would be better to configure some clock-dependent output and measure the frequency of that - a very obvious case being a serial UART you want to use for debug messages anyway, or perhaps a timer peripheral. Typically this is also downstream of the PLL, though clock trees on modern MCUs can be rather complex.