Fix all-None coverage treated as 100% in schedule handler

[hiroshinishio]

Summary

• Files never measured by the coverage tool (all three metrics None) were incorrectly skipped as "fully covered" in the schedule handler's candidate filtering
• E.g. web/pickup/finishp.php had stmt=None, func=None, branch=None and was silently excluded before even becoming a candidate
• Now only files with at least one actual measured metric at 100% (and the rest None/100%) are treated as fully covered
• Also fixed the sort key to handle None coverage values without crashing (TypeError: '>' not supported between NoneType and int)

Social Media Post (GitAuto)

Our test scheduler was silently skipping files that needed tests. The coverage tool returns None for files it never measured - and our filter logic treated all-None as "100% covered." One customer's PHP codebase had thousands of unmeasured files invisible to the scheduler. A three-line fix now distinguishes "never measured" from "fully covered."

Social Media Post (Wes)

Found a subtle bug in our coverage filtering. When a coverage tool doesn't measure a file at all, it returns None for every metric. Our code checked all(v is None or v == 100) - which is True when everything is None. So unmeasured files looked fully covered and were skipped forever. Took an AWS log dive on a customer repo to spot it.