Implement Lambda Labs provider methods

[devin-ai-integration]

Address GitHub comments: implement cloudcred system, update naming schema, and implement GetLocations

Summary

This PR addresses 4 GitHub comments from the initial Lambda Labs provider implementation by making significant architectural changes:

1. CloudCredential System Implementation: Added LambdaLabsCredential struct that implements the v1.CloudCredential interface with RefID support and MakeClient() method, following the dev-plane credential pattern
2. Instance Naming Schema Update: Modified CreateInstance to use dev-plane naming pattern RefID--timestamp (or RefID--name--timestamp when custom name provided) instead of simple name assignment
3. GetLocations Implementation: Replaced API-based location discovery with hardcoded JSON location data using the exact structure provided in GitHub comments
4. Capabilities Consolidation: Combined client and credential capabilities into a unified function and removed firewall capability since Lambda Labs doesn't support it at project level

The changes follow dev-plane patterns while adapting to the v1 interface requirements, but involve significant architectural modifications that require careful validation.

Review & Testing Checklist for Human

• Test complete credential workflow - Create LambdaLabsCredential → call MakeClient() → use resulting client for instance operations with real Lambda Labs API credentials
• Verify instance naming compliance - Create instances and confirm names follow expected RefID--2025-08-05-15-04-05Z00-00 format without conflicts
• Validate hardcoded location data accuracy - Check that the 18 hardcoded locations in lambdaLocationsData match current Lambda Labs available regions
• Test CloudCredential interface methods - Verify GetTenantID(), GetAPIType(), GetCloudProviderID() return expected values and GetCapabilities() works correctly
• Integration testing with error scenarios - Test credential creation with invalid API keys, client creation failures, and API error handling

Recommended test plan: Use real Lambda Labs API credentials to test the full flow: credential creation → client instantiation → location retrieval → instance creation to ensure the refactored architecture works correctly with the actual API.

---

Diagram

%%{ init : { "theme" : "default" }}%%
graph TD
    CredStruct["LambdaLabsCredential<br/>(client.go)"]:::major-edit
    ClientStruct["LambdaLabsClient<br/>(client.go)"]:::major-edit
    CreateInst["CreateInstance<br/>(instance.go)"]:::major-edit
    GetLocs["GetLocations<br/>(instancetype.go)"]:::major-edit
    Capabilities["GetCapabilities<br/>(capabilities.go)"]:::major-edit
    V1Interface["v1.CloudCredential<br/>(pkg/v1/client.go)"]:::context
    APIClient["Lambda Labs API<br/>(gen/lambdalabs)"]:::context

    CredStruct --> |"MakeClient()"| ClientStruct
    CredStruct --> |"GetCapabilities()"| Capabilities
    ClientStruct --> |"uses RefID in naming"| CreateInst
    ClientStruct --> |"no longer calls API"| GetLocs
    CredStruct --> |"implements"| V1Interface
    ClientStruct --> |"calls"| APIClient


    subgraph Legend
        L1["Major Edit"]:::major-edit
        L2["Minor Edit"]:::minor-edit  
        L3["Context/No Edit"]:::context
    end

    classDef major-edit fill:#90EE90
    classDef minor-edit fill:#87CEEB
    classDef context fill:#FFFFFF

Loading

Notes

Key Architectural Changes:

• Introduced credential-based client creation pattern with RefID tracking
• Changed instance naming from simple assignment to computed RefID--timestamp format
• Switched from dynamic API-based location discovery to static hardcoded data
• Consolidated capabilities implementation to eliminate code duplication

Risk Assessment: Medium-High - The changes involve significant architectural modifications to the credential system and naming patterns. While linting and basic tests pass, the implementation hasn't been validated against the real Lambda Labs API, so there may be runtime issues or API response structure assumptions that don't hold in practice.

Testing Gap: The most critical gap is lack of integration testing with actual Lambda Labs credentials. The new credential → client → instance creation flow needs validation to ensure it works correctly with the real API.

Link to Devin run: https://app.devin.ai/sessions/3c66bd2db2924dc4bbb8d5e739350214
Requested by: @theFong

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[theFong]

use the instance type api to get locations see devplane repo internal/cloud/lambdalabs

[theFong]

lets implement a cloudcred that turns into a client. This cloudcred should hold a RefId

[theFong]

look at devplane and use the naming schema there (after cloudcred is implemented and we have the reference id). Notice that we read the name out

[theFong]

implement this in capabilities.go

[theFong]

actually use this

const lambdaLocationsData = `[
    {"location_name": "us-west-1", "description": "California, USA", "country": "USA"},
    {"location_name": "us-west-2", "description": "Arizona, USA", "country": "USA"},
    {"location_name": "us-west-3", "description": "Utah, USA", "country": "USA"},
    {"location_name": "us-south-1", "description": "Texas, USA", "country": "USA"},
    {"location_name": "us-east-1", "description": "Virginia, USA", "country": "USA"},
    {"location_name": "us-midwest-1", "description": "Illinois, USA", "country": "USA"},
    {"location_name": "australia-southeast-1", "description": "Australia", "country": "AUS"},
    {"location_name": "europe-central-1", "description": "Germany", "country": "DEU"},
    {"location_name": "asia-south-1", "description": "India", "country": "IND"},
    {"location_name": "me-west-1", "description": "Israel", "country": "ISR"},
    {"location_name": "europe-south-1", "description": "Italy", "country": "ITA"},
    {"location_name": "asia-northeast-1", "description": "Osaka, Japan", "country": "JPN"},
    {"location_name": "asia-northeast-2", "description": "Tokyo, Japan", "country": "JPN"},
    {"location_name": "us-east-3", "description": "Washington D.C, USA", "country": "USA"},
    {"location_name": "us-east-2", "description": "Washington D.C, USA", "country": "USA"},
    {"location_name": "australia-east-1", "description": "Sydney, Australia", "country": "AUS"},
    {"location_name": "us-south-3", "description": "Central Texas, USA", "country": "USA"},
    {"location_name": "us-south-2", "description": "North Texas, USA", "country": "USA"}
]`

type LambdaLocation struct {
	LocationName string `json:"location_name"`
	Description  string `json:"description"`
	Country      string `json:"country"`
}

func (c LambdaLabs) GetLocations(_ context.Context, _ GetLocationsArgs) ([]Location, error) {
	regionData, err := collections.FromJSON[[]LambdaLocation]([]byte(lambdaLocationsData))
	if err != nil {
		return nil, errors.WrapAndTrace(err)
	}
	locations := collections.Map(regionData, func(region LambdaLocation) Location {
		return Location{
			Name:        region.LocationName,
			Description: region.Description,
			Available:   true,
			Country:     region.Country,
		}
	})
	return locations, nil
}

[theFong]

can we find a way to combine client + credential capabilities these? also is appears lambda does not support modify firewall since it is project level