Migrate project and MR-level scan_result_policy_reads queries

What does this MR do and why?

Several places in the codebase ask "does this project have security policies?" or "which policies target commits?" These questions were answered by querying the scan_result_policies table directly. With the adapter in place (!231013 (merged)) and services migrated (!231014 (merged)), the remaining gap is these project-level discovery queries — without updating them, the system would still depend on the old table to find policies in the first place.

This MR completes the migration by updating the entry points — the project-level and merge-request-level queries that decide whether policies exist and which policies apply. After this change, the system can discover policies through either the old or new table depending on the feature flag, and no caller queries scan_result_policy_reads directly anymore.

MR chain

This is part 3 of 4 in the scan_result_policies deprecation chain:

1. !231013 (merged) — Foundation: ApprovalPolicySource adapter, feature flag, ApprovalRuleLike integration
2. !231014 (merged) — Service callers: Migrate ~10 services/libs from scan_result_policy_read to approval_policy_source
3. !231015 — Project queries (this MR): Flag-aware has_approval_policy_rules? and approval_policy_rules_targeting_commits on Project
4. !231016 — Violation FK handling: Flag-gated violation create/delete using approval_policy_rule_id

References

#510281

Screenshots or screen recordings

Before	After

How to set up and validate locally

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #510281