Introduce ProjectPushRule for project push rules table migration

What does this MR do and why?

As part of the Cells 1.0 initiative, the push_rules table is being restructured so that each entity type (organization, group, project) has its own dedicated table. The organization and group migrations are already complete. The project push rules table switch is split into multiple parts. Implementation Plan:

1. Convert reads - Switch read call sites from push_rules to project_push_rules. 👈 (this work)
2. Convert writes - Switch write call sites from push_rules to project_push_rules.
3. Roll out FFs - Gradual rollout for reads, 100% at once for writes.
4. Clean up FFs - Remove feature flag conditionals.
5. Remove triggers - Remove DB sync triggers between the two tables.

This MR is the first part of converting reads. It sets the foundation before switching push_rules to project_push_rules call sites:

• Add ProjectPushRule model with PushRuleable concern.
• Add ProjectPushRuleFinder to abstract table lookup.
• Add has_one :project_push_rule association to Project.
• Add read_project_push_rules feature flag (disabled by default).
• Update Project#predefined_push_rule to read from project_push_rules behind FF.

The DB sync trigger keeps both tables in sync, so enabling the flag is safe and rollback is instant. A follow-up MR will switch the remaining read call sites (API, controllers, services).

Query plan

• New query in ee/app/models/ee/project.rb (#predefined_push_rule)

SELECT "project_push_rules".*
FROM "project_push_rules"
WHERE "project_push_rules"."project_id" = <ID>
LIMIT 1

Time: 4.146 ms
  - planning: 0.732 ms
  - execution: 3.414 ms
    - I/O read: N/A
    - I/O write: N/A

References

• Parent epic: &15534
• Project Push Rule migration implementation plan: #499156
• Issue: #588805

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.