chore(repositories): Dual write to the new ProjectRepository table when created related rows in other tables

[wedamija]

When creating RepositoryProjectPathConfig and RepositoryProjectPathConfig rows, we now dual write to ProjectRepository and store the id in the fk column.

[sentry]

Bug: The update() method in RepositoryProjectPathConfigSerializer doesn't update the project_repository foreign key, which can lead to the code mapping being deleted unexpectedly.
_{Severity: HIGH}

Suggested Fix

Update the update() method in RepositoryProjectPathConfigSerializer to fetch or create the correct ProjectRepository instance based on the new project_id and repository_id. Assign this new instance to the project_repository field of the RepositoryProjectPathConfig instance, mirroring the logic in the create() method.

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/integrations/api/endpoints/organization_code_mappings.py#L132-L137

Potential issue: When a user updates an existing code mapping's project or repository
via the `OrganizationCodeMappingDetailsEndpoint.put` endpoint, the `update()` method in
`RepositoryProjectPathConfigSerializer` is called. This method updates the `project_id`
and `repository_id` fields but fails to update the `project_repository` foreign key. The
code mapping remains linked to the old `ProjectRepository` record. Because the
`project_repository` field has `on_delete=models.CASCADE`, if the old
`ProjectRepository` is ever deleted (e.g., by unlinking the old repository from the old
project), the updated code mapping will be unintentionally deleted as well.

_{Did we get this right? 👍 / 👎 to inform future reviews.}