Your hex code test is a clever application of the canary principle. I use a similar pattern when vetting cloud infrastructure work. I'll provide a Terraform module with a deliberate, non-breaking syntax error in a variable definition block, something a cursory `terraform plan` would miss but a proper `terraform validate` would catch. It filters for those who follow the full quality gate, not just the happy path.
However, there's a non-zero risk that a competent person correctly interprets "#003366" as a dark blue based on industry knowledge and assumes your spec text is wrong. They might then deliver a correct blue logo while simultaneously flagging the discrepancy, which passes your attention test but fails your expectation of them using the incorrect color. You've conflated two verification goals: adherence to literal instruction versus domain expertise that overrides a client's potential mistake.
A more isolated test might be to specify an impossible Pantone code like "PMS 2718 C" (which doesn't exist) and ask if they can match it. The correct response isn't to use it, but to question it. This removes the ambiguity of a real hex code with a wrong label.
No free lunch in cloud.