Constraining Tco of source synchronous clock output

The reason it used the falling edge is because it's analyzing "clock as data" mode, where the clock is being used as data to the external register, since this is what is described. As data, both edges are valid, so both will be evaluated.

The clock is not normally constrained with either. By constraining your data outputs in relation to the clock, you've got it covered. (Similarly, you don't put a set_input_delay or set_max_delay on the clock coming in either). If those data paths ever fail, it's in relation to the entire clock path, so the clock path is indirectly being analyzed. Look at the Source Synchronous document I put on alterawiki for examples:

http://www.alterawiki.com/wiki/source_synchronous_analysis_with_timequest

Also note that your clock path is pretty rigid anyway. The PLL uses the phase-shift you select and is fixed. It drives a global clock tree, which is fixed, and gets off through the I/O. The only thing that really could change is the output delay chain in the I/O cell, but Quartus will keep that at 0 delay elements unless you enter a constraint that tells it to add more delay.