chore(repositories): Switch over queries for RepositoryProjectPathConfig to use the new ProjectRepository table

[wedamija]

This switches over SeerProjectRepository to start querying repos and projects via ProjectRepository. Also switches over attribute use.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit cf7aa2a. Configure here.}

[sentry]

Bug: The query in validate_code_mapping_id incorrectly filters out older code mappings with a NULL project_repository, causing validation to fail for valid mappings.
_{Severity: HIGH}

Suggested Fix

Modify the query in validate_code_mapping_id to correctly handle RepositoryProjectPathConfig records where project_repository is NULL. This can be achieved by performing two separate queries or by using a more complex query with Q objects to include both records with a matching project_repository__project and those with a NULL project_repository that match on the project field directly.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: src/sentry/issues/endpoints/serializers.py#L99-L103

Potential issue: When the `organizations:project-repository-fk-reads` feature flag is
enabled, the query in `validate_code_mapping_id` filters `RepositoryProjectPathConfig`
using `project_repository__project=project`. This creates an SQL `INNER JOIN` on the
`project_repository` field. Records created before a prior migration have this field as
`NULL` and are therefore excluded by the join. This causes the query to raise a
`DoesNotExist` exception, which is re-raised as a `ValidationError`. As a result, users
with valid, pre-existing code mappings are incorrectly blocked from creating or updating
CODEOWNERS.