Timing contraints/assignments for async. static RAM

Report Delay isn't a constraint, but an assignment that tells Quartus to report that delay. (The Classic Timing Analyzer is somewhat static in what it reports. It dumps a lot of information, but doesn't allow you to query for what you want. TimeQuest is much, much better for allowing you to search for paths.)

Look at the Ignored Timing Constraints portion of your timing report. I'm guessing your Tco assignment is there. It might say why, but the basic reason is that the output of a PLL is not a valid starting point for a Tco. (The reason being, the delay to the output of your PLL could theoretically vary from 1ns to 100ns and you'd still get the same Tco reported. This is why Tcos are reported from the source level clock). Also, I generally don't add a source when doing a Tco, but do a single point constraint. This means I put the name of the top-level port/s in the To column, Tco as the assignment, and the value I want in the Value column. The From column is left blank.

You can add this in the Assignment Editor and then just rerun the Classic Timing Analyzer(rather than a whole fit) and see if the constraint took, or if it shows up in the ignored constraints.

Also, your Tco should actually get better once it's analyzed from the clock port, because the delay through the PLL is negative(compensating for the PLL's feedback path). It won't go from 16.912 to under 7.5, but it should improve. And once you see a Tco panel where the port has a requirement, value and slack, so you know it's constrained, you can right-click on that path and do a List Path, which will give very detailed information down below.

As for constraining giving the impression that everything is under control, it absolutely should, and designs absolutely rely on constraints being 100% correct, but there is a non-trivial amount of design work in getting the constraints into the tool. (That goes for any static timing analysis tool...)