Update application logic for deploy keys to store organization_id

Overview

Update the application logic for deploy keys to automatically populate the organization_id field when creating or updating deploy keys.

Context

As part of the sharding key implementation for the keys table (tracked in epic &19679), we need to ensure that all new deploy keys have their organization_id set correctly. The database column was added in !208105 (merged), and now we need to update the application code.

Deploy keys are more complex than SSH keys because they can be:

• Project-specific deploy keys
• Shared deploy keys (used by multiple projects)

Requirements

1. Update Deploy Key Creation Logic

When a deploy key is created, the application should:

• Derive the organization_id from the project's organization
• For shared deploy keys, determine the appropriate organization
• Set the organization_id field on the key record
• Ensure the organization exists before creating the key

2. Handle Shared Deploy Keys

Special consideration for deploy keys shared across projects:

• Determine which organization to use (likely the first project's organization)
• Document the approach for handling shared keys across organizations
• Consider marking groups with cross-organization shared keys as "Not Isolated" (~1% of cases)
• Coordinate with Tenant Scale group if needed

3. Update Deploy Key Services

Review and update the following services/classes:

• DeployKeys::CreateService
• Any services that handle deploy key sharing
• Ensure all code paths that create deploy keys set organization_id

4. Add Model Logic

Update the DeployKey model (if separate from Key) or Key model to:

• Add logic to derive organization_id from associated project(s)
• Handle the case where a deploy key is associated with multiple projects
• Add appropriate validations

5. Add Tests

• Add unit tests for the model logic
• Add service tests to verify organization_id is set correctly
• Add integration tests for deploy key creation via UI and API
• Test shared deploy key scenarios
• Test edge cases (multiple projects, cross-organization scenarios)

Implementation Notes

• Deploy keys inherit from Key model, so check if shared logic can be used
• For shared deploy keys, use the organization from the first associated project
• The organization_id column is currently nullable (will be made NOT NULL in #577246)
• Document any limitations or special handling for shared keys

Acceptance Criteria

• All new deploy keys created have organization_id populated
• Shared deploy key scenarios handled appropriately
• All relevant services updated
• Tests added and passing (including shared key scenarios)
• No regressions in deploy key functionality
• Documentation updated for shared key handling
• Approach for cross-organization shared keys documented

References

• Parent Epic: &19679
• Database changes: #577242 (closed) (completed via !208105 (merged))
• Related: #577243 (SSH keys)
• Backfill: #577245
• NOT NULL constraint: #577246
• Investigation: #553463 (closed)

Additional Context

From the investigation issue, approximately 1% of deploy keys are shared across multiple projects. These cases need special handling in the Cells architecture.